Hey everybody As promised, here are some quick sketches of what I understand to be the different Sync options we're discussing. I hope this helps provide some visual help for this email discussion, and for the meeting we're having later today.
http://cl.ly/2m1G1914030E A lot of this seems to come down to - How simple should the Sync experience be for our users? - How flexible should the Sync experience be for our users? - How easy or hard is it to build the desired solution? - Will the desired solution scale over time? I should also add that in doing this, I have started to come around to the idea of supporting different sync settings on each of a user's different devices, if that's what they want. It adds complexity to the setup experience, but perhaps not as catastrophically as I had imagined in my head earlier. Anyway, would be great to get thoughts from others here as well. Thanks! Ian On 2013-08-29, at 5:57 PM, Chris Karlof <[email protected]> wrote: > (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
