> By saying "Sync Everything", I'm not proposing actual copy, but I'm proposing > the default is to sync all of your "Fx experience" (that we can).
I agree. That should be the greased chute. (My feeling is that we should be selling that to users, rather than hiding it in Sync Options (as current Sync does), but whatevs.) > I watched a user in the Portland user tests that used Chrome sync because > "all his stuff" is "just there". That's how I interpret our user story: "As a > user, I want to be able to pick up any new device and replicate my core > Firefox experience so I don't have repeat a bunch of work I've already done > on another device." I think user testing has also shown (Crystal, correct me if I'm wrong) that different segments of our user base have very different expectations here, to the point that there really isn't a common denominator — for every user who takes that Portland user's perspective, there's another who knows that they don't want Firefox syncing something that's important to them in some circumstances. One Size Fits Few. > After we nail the default behavior, the next question is how much > customization we provide. Customization is complexity and the big money > question is expected value vs cost. If hardly anyone changes the defaults, > the expected value is small. What data to we have? How many users change the > defaults in the existing sync system? How many users complain about or praise > the existing customization controls (caveat: noisy or stalwart users are not > necessarily representative users)? Another important data point is Chrome > sync, which defaults to syncing all the browser data and disabling a datatype > affects all connected devices. I suspect many of their UI decisions are data > driven, and it would be foolish to completely ignore their choices. I think there's a disconnect here in what we're talking about. In the short term, when we have a handful of data types, with one service, we can think of this in terms of "customizing defaults". (Even so there are pain points that that causes, which we've discussed elsewhere.) We will very soon be at the point of opt-in services (contacts, reading list, …), and a growing forest of things that sync. As Mark put it, that doesn't really fit the "checkbox model". I'm trying to (amongst other things) get us to address that discontinuity. I also want to push back on the broad-strokes characterization of "customization is complexity", because I think we've already established that users expect to be able to turn parts of this feature on or off. The question is about how we enable them to do that, and it's simply not true to say that restricting some axes of the UX there will reduce complexity, particularly given what we'll have to build to support Service #2+. The existing Sync UI demonstrates quite clearly that a "simple" solution can fail to meet user expectations as well as carrying with it additional engineering costs and bugs. _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
