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