----- Original Message ----- > On Aug 26, 2013, at 1:16 PM, Richard Newman <[email protected]> wrote:
> > Ian: FWIW Chrome's browser sync settings behave the same way -- one choice > > that affects all your Chrome browsers. This is from their Sync setup page: > > Richard: Chrome gets to avoid this problem by (a) having precisely one > > identity-attached service linked to your browser (the rest are pure web > > properties), and (b) having the same set of capabilities on every device. > > Neither of these applies to Firefox and picl, where we will have an > > extensible heterogeneous mess of data types and services. > > > Chrome is supported on (at least) desktop, tablet, and phone. These devices > do not all have the same capabilities. E.g., apps and extensions are not > supported on mobile versions of Chrome, but you can sync them between > desktop computers. So what we are suggesting is that the client will support or ignore certain data types in a hard-coded fashion, much like we do now in Firefox for Android? Off the top of my head I think we hard-code: * Do not sync add-ons * Do not sync all history. Only a subset so we don't blow up the bandwidth, CPU and disk space usage. > -chris > > In other words: the decision is about whether to expose some choice and > > flexibility, or sweep a lot of complexity under a very small carpet. My > > concern is that the latter will be a really bumpy road, both from an > > engineering perspective and as a user. > > > > (Phone; please excuse brevity.) > > > > > > -----Original Message----- > > From: Ian Barlow [[email protected]] > > Received: Monday, 26 Aug 2013, 12:17pm > > To: Richard Newman [[email protected]] > > CC: [email protected] [[email protected]] > > Subject: Re: Per-device syncing preferences beyond engineering milestone 1 > > > > > > I am all for giving users control, but I feel that in this particular case > > the "more flexibility == better for users" idea falls apart for most of > > the things our browser can sync. Passwords, history, bookmarks, even > > add-ons. For things like these, I can't really see the value in offering > > the choice to send different buckets of data to different devices, since > > the data types don't really line up with any meaningful contexts for the > > user. > > > > For example, even if I have a "work phone" and a "home computer" that both > > use Firefox, from the browser's perspective there's no way to distinguish > > the work passwords I need from the home passwords I need, nor with the > > bookmarks I've saved or places I've visited. It's more or less the same > > for Add-ons -- why can't Firefox know what addons are compatible across > > the different devices I use and sync the ones that work? > > > > I also think that kind of fine grain device-by-device decisionmaking is > > just too much mental load on the user, at least for browser-related data > > choices. > > > > > > > > " > > Changes are synced instantaneously. > > Any changes you make to your browser settings will be synced to the account > > you've used to sign in to Chrome. Changes you make on one computer are > > automatically reflected on the other computers where you're signed in and > > have enabled sync. > > " > > > > > > > > > > > > > > On 2013-08-26, at 3:01 PM, Richard Newman <[email protected]> wrote: > > > >> Hi all, > >> > >> In some smaller discussions we've observed that having a single set of > >> syncing options for all of a user's devices is going to get complicated > >> and painful. I thought I'd send out an email explaining very briefly why > >> I think that is, a couple of other points that this intersects with, and > >> a suggestion as to a way forward. We can dive in with more detail on each > >> point if we need to. > >> > >> In short: > >> > >> 1. Different devices don't have the same capabilities. We see this right > >> now with Sync on Android, which doesn't sync prefs or add-ons. The code > >> to support that with Sync's single-election model is hairy, and the user > >> experience is weird. > >> > >> 2. Different devices don't even have the same *services* -- maybe you can > >> sync with Pocket on your phone, but not on your desktop. Maybe you can > >> only sync the same data type with different services on different > >> devices! Now what? > >> > >> 3. We're going to be adding capabilities (add-on sync) and services (send > >> tab) over time. We need a way to surface those to users so they can opt > >> in. > >> > >> 4. Single-list is, IMO, just as surprising to users as having per-device > >> choices. For every user who would turn on bookmark sync on their desktop > >> after first-run and be surprised that it doesn't automatically turn on on > >> their phone, there's another user who turns off history to save bandwidth > >> on their phone (an MVP req!) and is surprised that their desktops are no > >> longer sharing history. This has been a noticeable point of negative > >> feedback from users with Sync's one-size-fits-all approach. > >> > >> 5. Automatically turning on or off data choices is a security hole, so > >> we're going to prompt. That experience is better if it's a choice, not a > >> veto: "You just turned on bookmark sync on your desktop. Do you want to > >> sync your bookmarks with this device?" rather than "You just turned on > >> bookmark sync. Allow this change, or turn it off everywhere?". And that > >> also surfaces #4. > >> > >> 6. For first-run, as I understand it, we would like to get users more > >> involved in the value prop of the feature, and we can do what we can to > >> migrate your choices from Old Sync. That's a good opportunity for doing > >> something smarter than Sync does now. > >> > >> 7. There's nothing to say that we can't streamline the user experience for > >> users who want it, once we've clued them in to what's happening: e.g., > >> "Do you want to sync your bookmarks with this device? [] Always sync new > >> data types". > >> > >> > >> My proposal: > >> > >> Given that we already need to show UI to users as data types change, and > >> given that we already need to support different capabilities and services > >> between devices, and given that we need to advertise new options to users > >> as they become available, I see only user pain and non-trivial > >> engineering complexity in trying to enforce a single list of services and > >> datatypes between devices. > >> > >> A single list makes some amount of sense (leaving only points 3 and 4) if > >> every device is the same -- like Firefox Sync 2009-2011 -- but that will > >> very rapidly become false in the new world, and we should act > >> accordingly. > >> > >> Instead, let's keep the experience simple where it can be, allow for > >> discovery, ask for confirmation when we might be wrong, and allow the > >> user to choose when we can't make even a half-decent choice on their > >> behalf. > >> > >> > >> Thoughts, particularly from a product perspective? > >> > >> -R > >> _______________________________________________ > >> Sync-dev mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/sync-dev > > > > _______________________________________________ > > Sync-dev mailing list > > [email protected] > > https://mail.mozilla.org/listinfo/sync-dev > _______________________________________________ > Sync-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/sync-dev
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
