(re-posting w/o the screenshot - the mailing list gods complained)
Thanks so much John for putting this video together, and I'm sorry the
community can't view it.
Here's my notes on John's video ("C****" are my way of obscuring the names of
the users):
W**** 1:00
- Sync made more sense when it showed her the data she was syncing
- doesn't need passwords on phone because she doesn't go to sites she needs
passwords on her phone
- de-selected History but didn't explain why
- doesn't use bookmarks
- likes tab syncing
T**** 1:39
- predicts what it will sync
- will use history to find things he needs to visit again
M**** 2:13
- unclear at first what it's syncing because guesses reasonably
- doesn't want to sync history (doesn't get the value prop)
A**** 3:08
- wants Roboform synced
K**** 4:19
- doesn't know how to add her phone (thinks she can add it after she logs into
desktop)
- also doesn't see the value prop of history syncing
My main takeaway:
Selling sync's value prop as a verbatim list of datatypes it syncs doesn't cut
it. These are, IMO, implementation details. The benefits are not clear,
*especially* for history. IMO, the test users wanted to disable history sync
because they didn't see any benefit in enabling it.
Take a look at Chrome sync's value prop page:
https://www.google.com/intl/en/chrome/browser/signin.html
"History" is scarcely mentioned. Instead, "Omnibox, Get autocomplete
suggestions for the sites you visit most." (screenshot attached)
"History Sync": wtf.
"Awesomebar Sync": hell yes.
-chris
On Aug 28, 2013, at 1:47 PM, John Gruen <[email protected]> wrote:
> User testing video highlighting data type selection:
> https://mozilla.box.com/s/suy4c5d8ktu7t1vtei1a
>
> To access the video, you must have a Mozilla Box acct. I can find alternate
> means of sharing if need be.
>
> This video highlights three interrelated findings:
>
> 1. Different users want different data types synced.
>
> 2. Choice promotes a better mental model of PiCL.
>
> 3. Users may not understand the value-added of syncing history and/or there
> may be benefit in more refined methods of syncing history (most visited
> sites, etc.)
>
>
>
>
> ----- Original Message -----
> From: "Karen Rudnitski" <[email protected]>
> To: "Mark Finkle" <[email protected]>, "John Gruen" <[email protected]>
> Cc: "Chris Karlof" <[email protected]>, [email protected], "Richard
> Newman" <[email protected]>, [email protected]
> Sent: Wednesday, August 28, 2013 10:29:34 AM
> Subject: RE: Per-device syncing preferences beyond engineering milestone 1
>
> I am of the opinion at the moment that there are – and can be – services
> attached to the Firefox Account. I think the biggest point of debate is how
> granular the ‘services’ get.
>
>
>
> If I were to think about what syncing ‘my’ firefox would be, it would be a
> group of what you would define as a bunch of separate services – where I see
> that grouping as what helps define what ‘my’ firefox would be. I think
> about what makes our current experience Firefoxy, and I think about password
> management, about the awesomebar behaviour and my bookmarks (I don’t really
> think about tabs at all). Therefore I see this as ‘one’ service that we
> would be attaching to the account – and for the more ‘wizard’ like
> behaviour, we should be able to allow users to choose what is syncing. But
> we should be appealing overall to the larger market who are looking for
> ‘their’ firefox on more than one ‘device’ and ensure they understand what is
> syncing and why as per good contextual messaging (as per MVP request).
>
>
>
> Future services can then be attached to the Firefox Account – either as a
> collection of smaller ones or disparate, standalone options depending on
> what and how we implement.
>
>
>
> I don’t think there is any disagreement about attaching disparate, separate
> services to the Fx Account as I think we all see this as the mechanism to
> provide an expanded set of options valuable to the user. I think the biggest
> point of debate if what makes ‘my firefox’ ‘my firefox’ – a collection of
> smaller ‘services’ or individually chosen services. I’m still leaning
> towards the former instead of the latter, because I’m thinking about our
> segmentation and that I think we have fallen down on providing good,
> understandable context in the past (which I am confident we can fix for MVP
> given our UX and copywriting skills within the org).
>
>
>
> Karen
>
>
>
> From: Sync-dev [mailto:[email protected]] On Behalf Of Mark
> Finkle
> Sent: August 28, 2013 8:20 AM
> To: John Gruen
> Cc: Chris Karlof; [email protected]; Richard Newman; [email protected]
> Subject: Re: Per-device syncing preferences beyond engineering milestone 1
>
>
>
>
>
> 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.
>
> I disagree with the concept of "one central service" and instead think about
> it like "many identity attached services" connected to a Firefox Account.
> There are many more services on the "future list" that would also be
> connected to a Firefox Account.
>
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
