On Tue, 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. > If we can stand to sit tight till we design folk can put some new revisions on the mocks (which will come very soon), I think we'd have a much more productive conversation. I don't know how we'll solve this problem yet. This is a problem the four of us are going to have smash brains together to weigh how we can best explain the service. My hope was that allowing data type selection at time of sign up *might* be a way to make more clear to people what they were signing up for as well as allaying any fears that they were sharing more data than they wanted to. > > 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'm not following you here, to be honest. Maybe I'm just not that smerht. I really only can design for the MVP and v2. Anything beyond that has so little specificity that it is beyond my ability to imagine the UX. > > 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. > I'm not asking for zero complexity. I was the one asking for data type selection, after all. :D What I am saying is that I can't even imagine what a UI that allowed you to sync passwords on this device, but your desktop has syncing passwords turned off, so... you're still not getting your stuff from point A to point B. Yah. I don't even know where to begin on making a UI that would clearly display all those states, especially in the small space we have on mobile. c
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
