On Aug 26, 2013, at 1:16 PM, Richard Newman <[email protected]> wrote:
> The choice is whether you try to sync all of the same groups of buckets to > every device, given that it's impossible to do so, and how you explain that > gulf of inconsistency to the user. > What I'm hearing from product and UX is that at least for the current browser-data-centric datatypes, global (i.e., one setting for all your devices) selections are sufficient or desired. I think this is fine, and doesn't prevent use from tracking per-device capabilities to enable more nuanced behavior in the future. > * Firefox finds a new service (e.g., by installing an add-on)? Does it turn > on by default? The default should probably be "Sync Everything", which probably means we sync new datatypes as we add them for users who don't change the default. If a user changes her elections (i.e., opts out of some datatypes), new datatypes are not synced unless the user turns them on. > * When another device starts syncing to a service that this one can't talk > to? Do I turn it off on that other device, or do I have per-device options > that the user just can't control? Leave it on, devices that don't understand this datatype ignore it. This seems fine to me. I don't really see it as a "gulf of inconsistency". > > * ... A datatype I don't have, or for which I don't have syncing code? (which > will be most feature releases) Again, do I turn it off on that other device, > or fork? > Ignore that datatype on this device. Again, it don't see it as a "gulf of inconsistency". > * When I now support syncing that thing, do I quietly sync up and down a > bunch of stuff that hasn't been syncing for months, probably to great user > surprise? If not, do we have to turn off sync for that stuff on your other > devices? We'll have to consider this on a per-datatype basis, but the simplest thing to do is to treat it like a "new device attach" for that datatype (i.e., merge-local-into-server-and-start-syncing). > * What happens when I try to turn off a data type on my phone because I'm > bandwidth sensitive or history is making my phone slow? A global settings approach obviously doesn't let you do this. Product and UX need to weigh in. I believe there are alternative ways of addressing this other than per-device management for all datatypes. For example, if we have evidence that a significant number of users want to disable history syncing on their phone for bandwidth reasons, we could offer a "Bandwidth Management" menu (Chrome Mobile has such a menu for other reasons) that has an option to "Disable or Limit History Syncing on This Device" > * What happens when my phone supports syncing reading list to Pocket, but my > desktop supports syncing reading list only to a different service? When I > pick that service on one device, what happens on the other? Can they both be > turned on? If so, what happens when you install Pocket on your desktop? Do we > switch and merge automatically? Have we nailed down what it means to "sync your reading list to Pocket"? You *could* actually "sync" your reading list with pocket, but that seems a bit rigid. A way that I've seen other apps integrate with Pocket (and Evernote, Buffer, Pinboard, etc.) is to "share" or "send" to Pocket, and they way you read this data is to just go to Pocket in your browser or mobile app. This lets us support multiple sharing services without actually syncing this data to a local data store. Syncing a local data store to multiple services is messy. Thinking of services like Pocket as "sharing" services makes a lot of the problems you brought up go away. These would be for datatypes that live in the cloud, not in your browser(s). -chris > 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. > > 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. > > 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 _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
