I'm in agreement with Ian here. Of course, I'm open to revisit, but I do think that our first hurdle is introducing our users to a 'sync account' and have them manage settings related to the 'account' and not on a 'per device' basis. Otherwise it becomes too complex not only to explain, but I also am not sure we could manage appropriately the expectations the user would have (would they remember what settings they applied for their tablet vs phone vs desktop? Would they even *think* to check those settings or just get frustrated that something wasn't behaving as expected)?
I think we should approach our new 'sync account' as just that - and not as individual devices with sync running on them. Although I can understand some of the engineering benefits of having the individual data choices, I am not convinced it would be to the benefit of the overall user experience. Karen From: Sync-dev [mailto:[email protected]] On Behalf Of Ian Barlow Sent: August 26, 2013 3:17 PM To: Richard Newman Cc: [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. 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
