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. -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
