>> * As a user, I want optionally to specify which types of data will be synced >> before I have to create a Firefox Account and log in to my browser. During >> this process, I want to be able to get more information about what each type >> of data is and what it means for me in terms of browser functionality, >> potential bandwidth usage, and what happens to that data after I have logged >> out of my browser. > > a) I personally think this is useful, but when such an idea was discussed for > Old Sync we worried about putting to much information in front of the user > and increasing sign-up friction.
This is why Sync Options is hiding behind a button during Old Sync setup. The goal was to minimize friction but still surface the options, given that many users won't ever open prefs and find the Sync tab. I have a notion -- which it seems that Deb is conveying here -- that perhaps setup should be more of an experience that conveys a value prop as well as soliciting elections, and thus treating these as checkboxes to hide was the wrong direction. If UX and product agrees with that notion, I see no issue with this story or with surfacing that choice before sign-up. >> * As a user, I want to be able to modify my Sync data settings in my browser >> at any time after I have set up Sync and am logged into my Firefox Account. > > a) We support this in Old Sync, but we think it's very infrequently used. In > fact, it's been a source of bugs, since browser bugs and client races have > sometimes corrupted the settings, resulting in impenetrable results. We're > already planning to surface this more prominently; question is, is it an MVP > story? Well, the buggy implementation of engine enablement has been a source of bugs :D I would gently assert that allowing users to make elections during initial setup, but not allowing them to change them later (e.g., when they set up a new phone and realize they don't want their history syncing), would be surprising and user-hostile, and would result in behaviors like "bloody Firefox, I have to start over and set up a new account". And in order to support the initial election of preferences at all, we have to build most everything but the prefs UI. So would I block ship for this? No; we didn't for Android Sync. But I do think it's part of the overall story in the near term, and unlike for Android Sync we have user research that suggests that this area is important. > b) I see this as part of the devices API. So far, we haven't specced that at > all, so we can't say much about how long it will take to build. I would > expect weeks. I view this as motivation for both inclusion and exclusion: some of the ways to address this story could be short-sighted, considering the options we want to give users around 'connectors', third-party providers, etc. If we include it, we should make sure that we're not building it in a way that's wasted work or that hampers our ability to do it right in a multi-provider world. >> Testing also suggests that we give users a clear set of choices about what >> to do with their data when they sign out, such as "delete bookmarks" and >> "forget passwords", etc. I think for now -- as long as we clearly explain >> what happens to the data on sign out -- we can put this off until a later >> release, but if you disagree strongly please say so. > > I see this as being the other side of "clear local data". Since we have no > clear story around what "clear local data" means in a connected, New Synced > world, this can't be part of any MVP. On the other hand, the *user* story is absolutely clear -- I want to know (or have some choice) what will happen when I take certain actions. That we don't have a good answer means that coming up with defined and expected behaviors (or options for same) -- a continuation of the discussion in Bug 578694 -- is a project for Deb :D I'd agree with Deb that communicating what will happen -- in signing out, but ideally also when taking actions like Clear Private Data -- is MVP, and that giving the user some choice in how their actions will propagate is fodder for a later release. _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
