On Aug 27, 2013, at 11:20 AM, Richard Newman <[email protected]> wrote:
> 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. > > 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. I haven't seen the evidence or data to know conclusively whether this is a One Size Fits Few or One Size Fits Many situation. Can you point me at something that suggests it's One Size Fits Few? For example, these would be helpful: % of users in existing Sync that have changed the default elections, or a substantial number of SUMO requests that suggest users are confused by the election datatype election UI or decline to use Sync because the UI doesn't meet their use cases. I've asked John to help us drill down on the Portland testing results to help me us better understand those users' concerns with syncing different datatypes. > > 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+. I'm with Crystal, in that I'm having trouble understanding the requirements of things that are underspecified. Richard, you said we will have "a growing forest of things that sync". It would make our life easier if we avoid that when we can. Syncing is hard, and it would be easier to build future services as cloud services or things that interact with other cloud services. IMO, Fx Reading List is a natural fit for a cloud service, even though that's not how it's currently built (it's a local service, that we're talking about syncing - yuck) . Pocket is a conventional cloud service -- it's not a syncing service like Dropbox or CouchDB. -chris _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
