Chris' email came through as I was writing this; I will have specifics from our PDX session for everyone to mull tomorrow AM...
>Exactly the kind of thinking I'm looking for. I have started to think about >these data types (passwords, history, bookmarks, etc) as individual services. >Any given human will be putting different value on a particular data type. If >we raise them from simple data types and think about them as first-class >services, I think it allows us to better serve those users. For example, we'll >start finding ways to promote the "Password service" and not think about how >to display the "Password checkbox". Two things we saw in testing (and i'm currently putting together some highlights on this) was that: A. All users didn't want to sync the same data types B. checkboxes provided an important part of helping users establish a mental model about what exactly PiCL was and . Point A speaks to the way different users think about the (dis)continuity of their identities across devices. Point B speaks to the fact that Firefox Sync only became intelligible as a service once users had control over the parameters of the service. Users didn't enter into testing with the concept of Firefox as a cross-platform service provider, and the ritual of choice helped them understand this pivot. I don't think check boxes in particular were significant, but the act of choosing certainly was. When you say that we should think about data types as 'first class services' I understand you to mean that they demand more respect than the humble (deeply nested) check box provides. I agree to an extent, and think we can focus more closely on how we display PiCL as well as the UI/UX of selecting individual data types. However, I think it's super important to do all of this under the clear aegis of one central service. To wit, it seems like we should be thinking about data types as user-determined touch points that help define the service. JG ----- Original Message ----- From: "Chris Karlof" <[email protected]> To: "Richard Newman" <[email protected]> Cc: "Mark Finkle" <[email protected]>, [email protected], [email protected] Sent: Tuesday, August 27, 2013 6:05:08 PM Subject: Re: Per-device syncing preferences beyond engineering milestone 1 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 _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
