< User Services | Sync
Last updated: 2014/01/10
- 1 Tracking
- 2 Goals
- 3 User stories
- 4 UX design
- 5 User research
- 6 Migration strategy
- 7 Change log
- See: Sync MVP tracking
The goals of this MVP release of the new Sync service are to:
- Replace the existing Sync service with a persistent & scalable system, that closely (but not precisely) matches the old Sync functionality
- Introduce and integrate with the new "Firefox Account" service
- Significantly improve the Sync UX so more people will set up and use the service
- Migrate a majority of existing Sync users to this new service
Note that the stories on this wiki page do not represent the canonical list. The canonical list of users stories is maintained on Bugzilla and linked to this tracking bug.
- Firefox for Android: https://wiki.mozilla.org/Mobile/Projects/Firefox_Accounts_with_Sync_1.1_integration#Firefox_for_Android_MVP_-_contextual_user_stories
- Firefox for Desktop: https://wiki.mozilla.org/User_Services/Sync/Relaunch#Desktop_MVP_User_Stories
Future (Milestones 2+)
Core user stories
Set-up & Account Management
- As a user, I want to be able to detach my Firefox Account on a device, and be assured that my account and its related data will be preserved on Mozilla's servers, so I can access it later either with this or other clients.
- As a user, I expect Firefox Sync to securely encrypt all of my passwords that are managed by my Firefox Password Manager so they cannot be accessed by anyone else, regardless of whether they have access to data on the Sync servers.
- As a user, I would like the option of encrypting all of my Sync data in such a way that my data is completely unrecoverable if I lose my password.
Feature Usage Information
- As a Mozilla Product Manager, I would like to know how many users are using sync across which devices, and how many devices each user is syncing to their account.
Performance & Stability
- As a user, in the event of Sync service interruptions, I expect zero data loss across all of my devices, even if Firefox cannot access the Sync servers for an extended period of time.
- As a mobile user, I expect Sync to be as bandwidth-conservative as possible, minimizing re-downloading or re-uploading data in event of system errors or other issues, and otherwise ensuring that bandwidth used should be approximately proportional to the volume of changes.
- As a user of a more limited mobile device (ARMv6, FirefoxOS), I expect Sync to be able to intelligently scale down in terms of the amount of bandwidth and storage it uses so it does not excessively tax my data plan or storage space.
- UX flows for mobile and desktop available at https://wiki.mozilla.org/Identity/UX
Transition plan to FxA Sync in Fx29: User_Services/Sync/Transition_To_FxA_Sync.
The below material is maintained as ideas for future transition/migration plans.
- We want to encourage existing Sync users to migrate to a Firefox Account, without harming the experience of users who aren't ready to move.
- We're aiming for an overlap period between Sync and Sync.next. This will reduce the risk of users having partitions in their devices, reduce problems with upgrade/downgrades and staged releases, etc. The exact duration of this overlap period will depend on several factors: complexity, cost, time to market, and market parity.
- Delayed upsell. We want to sell Sync.next and Firefox Account once users are ready to upgrade -- that is, they have the right version of Firefox on each of their devices.
- Forcing function. As we ramp up, we'll remove the ability to set up an old Sync account from each product. Eventually we will force users off the old service and decommission it. See overlap period.
- Detect specific states.
- Non-email Sync account name. No migration possible.
- Single device. Encourage migration! No partitioning possible!
- Self-hosted. Offer to migrate to Mozilla's system if there's no locked pref to indicate that that's not desirable, provide docs to support continued self-hosting, inform the user of decommissioning plans so they can make an informed choice.
- Offer to set up a new Firefox Account using their same email address. Enter the normal account setup flow, which will take care of email verification. Don't reuse the password -- it's gone over the wire, many users won't remember it, and it's probably neither strong nor memorable.
- Preserve data syncing preferences, also allowing user to make new decisions at this point.
- Write decommissioning sentinel into the old Sync account. (bug 895526, bug 895518.)
- Disable or delete local Sync.old account.
- Clean up local prefs for sanity.
- Configure to intercept old account hooks e.g., Send Tab intents.
- Only one flag day requiring user involvement.
- Migration of data.
- Simultaneous syncing to Sync.old and Sync.next.
Open issues and action items
strikethrough when complete. Thanks!
- [lloyd] How long is the overlap period? Need to know some operational costs.
- [rnewman, mfinkle] What's the client engineering burden to having an overlap period?
- [rnewman] Send Tab isn't in the PICL IdP. We're trying to find out how important a feature this is for parity.
- [product] We know we plan to disable the account setup UI during ramp-up. At what point do we want to disable *login*, for those poor suckers who reinstalled Windows and want to get their data back from Sync?
- [product] When should we kill the Sync promo on Android? Depends on how valuable it is and how long our roadmap is for Sync.next.
- [?] Add-ons that provide sync engines will be screwed.
Original etherpad for notes
- 2013/09/05 - Removed all Milestone 2+ "Set-up & Account Management" user stories, as they have been moved out into v2 or further.
- 2013/08/26 - Changed "Milestone 2" section to be "Future (Milestones 2+)" to better reflect reality.
- 2103/08/20 - Removed "before I have to create a Firefox account" from data selection user story in m2.
- 2013/08/20 - Reworded user story in m1 "Securty & Encryption"; added two user stories to m1 "Set-up & Account Management"; Added 3 stories to m2 "Set-up & Account Management". All of these are marked as NEW.
- 2013/08/15 - Minor wording change to user story: "As a user, I would like the option of encrypting all of my Sync data in such a way that my data is completely unrecoverable if I lose my password."
- 2013/08/15 - Split user stories up into Milestones 1 & 2 based on recent discussions on the sync-dev@ mailing list. At this point it still needs final review by Engineering leads and Product owners.
- 2013/08/12 - Added "Only one flag day requiring user involvement" as a migration design requirement.
- 2013/08/06 - Minor wording tweaks to the Goals section based on feedback from Lloyd & Andreas.
- 2013/08/02 - Modified first-run set up user story to be for Firefox for Android only.
- 2013/08/01 - Removed all "Migration from Old Sync" user stories as they were placeholders - new stories will be added soon. Added "Migration Strategy" as a new top level section so all of this is in the same place.
- 2013/08/01 - Changed "Draft" banner to "Last updated", minor wording change in the "Goals" section.
- 2013/08/01 - Moved page to "User Services/Sync/v1" (and left a redirect in the original location); removed "What is this?" section; added "Tracking", "Goals", and "UX design" sections.
- 2013/07/31 - Minor wording changes, added two new user stories to the "Set-up & Account Management" section (currently the first two).
- 2013/07/19 - Changed "disable" to "detach" when talking about "disabling sync" on a device (dria)
- 2013/07/19 - Changed wording of bookmark sync user story so all mobile devices add bookmarks to the same "Mobile" folder, not one per device (dria)
- 2013/07/19 - Sent link to sync-dev@ list for review (dria)