Hi Chad, On Jan 3, 2014, at 4:39 PM, Chad Weiner <[email protected]> wrote:
> 1. I think part of the hold up in agreeing to a "let 'em be" route has been a > question of the "costs" of maintaining current and new sync. Some of those > costs are what you identify as open questions around UX that need to be > answered. I don't know if there are other costs, technical or otherwise; I > suspect most of the costs are UX related in trying to minimize confusion. > Getting clear on these costs would be a huge help. IMO, the bulk of the risk for confusion comes when a user gets "partitioned", meaning a user has some devices connected to FxA Sync and some devices connected to Existing Sync. In the "Let 'em be" plan, this risk is primarily introduced when a user goes to add an additional device. This could happen to an existing Sync user that decides to create an FxA Sync account instead of doing pairing or vice versa. The main tool we have in this case is messaging. > 2. You express a lot of concern around upselling current sync users to new > sync. We will come back to the question of upselling in a moment, but in > this plan, what is the experience of an current sync user who decides to > create a FxA? We could think about ways to get really targeted with our > messaging and limit the amount of noise we make to current sync users about > new sync, but we can't completely shield the current sync user from learning > about accounts. The current assumption is still that we're going to make a > lot of noise around the launch of 29 (for reasons Austrails and to get as > many users to create an account as possible). We can of course revisit that > assumption, but I'm unclear about the implications for current sync users > in your plan. What's the risk of a current sync user creating an account? > A current Sync user that logs into a new device with FxA Sync will be at risk for a partitioned experience. Unfortunately, these risks will exist in any plan that doesn't completely block adding new devices in Existing Sync. One argument for upselling/transitioning is to get us past this scary period (where many Existing Sync users can "accidentally" log in to/create account for FxA Sync) as quickly as possible. The downside of upselling/transitioning in Fx29 is that we're intentionally exposing users to UX paths that can potentially lead them to partitioning when we only had 18 days to design and build that experience. > 3. This may be related to #2, but I'm unclear on what exactly won't work with > Sync on Fx29 in your idea below: > The default "Create Account" screen for Sync will change to use FxA. We > include warnings that this won't work with Sync on Fx29- or Sync with > pairing. For users looking for "Existing Sync", we also include a link that > will direct them to the Existing Sync "Setup Sync" and "Pair A Device" > screens. > It should work fine. The notable distinction that hasn't been discussed before is that we allow users to create *new* Existing Sync accounts, if they prefer. But it's not the default, and they may need to click on some 8pt font link the lower right corner to initiate that flow. thanks -chris > > Thanks! > CW > > > On 1/3/14 3:59 PM, Chris Karlof wrote: >> Hi all, >> >> I see today listed as the deadline for a decision on a transition plan. I >> haven't seen significant discussion on this over the last day or two. >> >> What I've seen is: >> - https://wiki.mozilla.org/User_Services/Sync/Migration >> - https://services.etherpad.mozilla.org/sync-migration >> - >> https://www.lucidchart.com/documents/edit/4678-1408-52b1b652-9823-7a810a00c462 >> (Sync Migration tab) >> - Brendan asking "why given how sync works now, we can't keep the option for >> those users who want the same secrecy property they have now" >> >> The most concrete transition proposal I've seen is by Richard and Ryan F., >> largely captured in the Lucid chart linked to above. It's largely sensible, >> but it includes elements that I don't consider minimal (e.g., auto >> transitioning users and upselling). >> >> Here's my proposal for a bare minimum strategy for an *initial* transition >> from Existing Sync to FxA Sync. >> >> tl;dr Just let Existing Sync users be. Support FxA Sync and Existing Sync >> side by side in Fx29 with no attempt to upsell or transition from Existing >> Sync -> FxA Sync. >> >> What this means: >> 1) For users that are already connected to Existing Sync, Existing Sync will >> continue to work when they upgrade to Fx29. There will be no upsell to FxA >> Sync, and no attempt to transition them to FxA Sync in Fx29. Just let 'em >> be. In Fx29, these users will see no evidence of FxA Sync without >> disconnecting from Existing Sync first. >> 2) The default "Create Account" screen for Sync will change to use FxA. We >> include warnings that this won't work with Sync on Fx29- or Sync with >> pairing. For users looking for "Existing Sync", we also include a link that >> will direct them to the Existing Sync "Setup Sync" and "Pair A Device" >> screens. >> 3) The default "Login" screen for Sync will change to use FxA. We include >> warnings that this won't work with Sync on Fx29- or Sync with pairing. For >> users looking for "Existing Sync", we include a link that will direct them >> to the Existing Sync "Setup Sync" and "Pair A Device" screens. >> >> What this means for the future: >> 1) We don't necessarily have to commit to a sunset date or strategy for >> Existing Sync *now*. New users will (most likely) get FxA Sync and old users >> have the capability to continue to use Existing Sync, if they desire. >> 2) In Fx29, we lay what technical groundwork we can for a future sunset >> date, e,g, deprecation messaging channels. >> 3) In Fx29, we lay what technical groundwork we can for future transition >> strategies and upsells, e.g., starting to record the Firefox version of >> connected sync clients. >> >> Why I think this strategy is a good idea: >> 1) It's the simplest thing I can think of that both gets FxA Sync out the >> door and minimizes disruption for existing Sync users. It's simple enough >> that I feel confident that it "won't be terrible" for Existing Sync users. >> If an Existing Sync user doesn't attempt to the add a new device, her >> experience will be identical to what it is now. >> 2) It buys us time to design, build, and test transition and upsell >> strategies from Existing Sync -> FxA Sync that we can land in Fx30+. IMO, >> upsells and auto-transitions are non-trivial, and add both technical and >> schedule risk. We have 18 days left! >> 3) We mitigate negative press (for now). We aren't sunsetting pairing based >> Sync yet. For users that want to continue to use that, they can (for now). >> This strategy also addresses Brendan's question of "why given how sync works >> now, we can't keep the option for those users who want the same secrecy >> property they have now". If we're lucky and clever, we potentially add >> pairing as advanced security option for FxA Sync in future releases, in >> which case won't ever have to sunset it completely. >> >> Proposed next steps: >> 1) Make a decision (Chad, Karen, Jonath, Mayo, ?). Deadline: Dec 6. >> 2) Flesh out the details and UX more, particularly what some of the "Create >> Account" and "Login" screens would look like multiplexing FxA Sync and >> Existing Sync. (Note: even if we don't go with this proposal, we need to do >> this work anyway, unless we plan on completely eliminating the option of >> connecting to Existing Sync accounts in Fx29.) Deadline: Dec 7. >> >> -chris >> >
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
