We will need to nail down the UX for the sync migration - as a first cut, see bug 1014406 comment 1 - this bug is to turn that into real and specific UX around the sync migration.

Marco: this is a breakdown bug that should be taken by a UX person - not sure how you annotate those but it should be clear that it's a breakdown.

Thanks Gavin, updated the Bug title.

Hey Mark, I'm pasting in a link to Ryan's beautiful PDF: https://www.lucidchart.com/publicSegments/view/5387908b-d24c-47ae-956f-67d50a0090ac/image.pdf Best not to add as an attachment to the bug just yet b/c the PDF is generated dynamically and Ryan may want to update it a bit after you guys chat.

I think it makes sense to have the UX specific discussion in this UX bug. (In reply to Ryan Feeley from bug 1014406 comment #6) > Hi Mark, here is a complete vision for the migration experience (download > this PDF which links to other PDFs) that includes notification bars, > preferences, the Australis menu and more. > http://is.gd/sync_migration_ux_pdf > Covers the gamut. Thanks Ryan. Some questions: * "Sync Migration Onboarding" says "first run only". I doubt this means that the new entry in the hamburger menu should only appear on that first run and never again (the user may not even open the hamburger menu on that run), so can you clarify? * I think there is still an outstanding question regarding the "triggers" for the actual migration flow. I've been assuming this would be in response to the servers sending the EOL notification, if for no better reason than it leaves services in control of the rate and even gives the ability for them to stop sending it completely for some period (eg, if they have some maintenance issues that would affect the reliability of sync, they could stop sending EOL notifications until the problem is resolved). The existing flows don't seem to capture this - they assume we just blindly offer to migrate at startup, which wouldn't be a smart thing to do if sync happened to be down! Similarly, the user might be behind a captive-portal or not connected to a network at all, so not be able to reach the sync servers to begin the migration - having us migrate due to a response from the server means it is far more likely the servers are actually reachable. * Related to the above, I think the "join the party" box will be tricky - it will only be *during* the migration process that we can determine with certainty if other devices for the user have been migrated (or possibly after a normally scheduled sync) - ie, I'd be reluctant to attempt to perform this check at every startup - it will involve hitting the network - and I think it would be better done once the user has opted-in to the migration. * I'm still not clear on what UI we will show when we are waiting for user action - eg, when waiting for the user to signin to FxA, waiting for the verification mail or waiting for us to communicate with the sync servers. This needs to take into account the fact that the browser might exit during this time. I'd expect the notification bar *and* the hamburger panel to change state during this time to reflect a migration has started but we are waiting for something. * As above, the flows don't seem to take into account that the user may have started migration in a previous run. IOW, I'm expecting to see the first entry to say something like "has migration already started on this device?" - but as above, I'm also not sure this should be at startup, but instead in response to an EOL notification from the server.

> "Sync Migration Onboarding" says "first run only" The blue-circle tickling of the Australis menu item would only happen once, on the relaunch of the updated browser. > I think there is still an outstanding question regarding the "triggers" Agreed, it would have nuance than represented in the diagram. I will defer to you on the best treatment for this. Throttling, server load... I'm not sure there's much I can add. I added one more "if" state to the diagram. > RE: Join the party The challenge here is that the call to action is going to be for registration. We need a sign-in call to action once the account has been migrated anywhere in the sync pool. > Waiting for verification This is depicted in the "pre-verified" state, again here: https://www.dropbox.com/s/0l8aj6sjgjz0xbw/Sync%20Preverified.pdf > "has migration already started on this device?" If the user has not reached the "email sent" state, the process starts over again (I've updated the diagram to reflect this).

(In reply to Ryan Feeley from comment #5) There are a couple of other things I'd like clarified here - we can chat a little more in the meeting tomorrow, but hopefully this will give some context. > > RE: Join the party > The challenge here is that the call to action is going to be for registration. > We need a sign-in call to action once the account has been migrated anywhere > in the sync pool. OK - but this will take time to determine. Consider a user who clicks on the item "Firefox Account Needed for Sync" on the hamburger menu. While the chart doesn't show this, I assume the intent is to go directly to the "if sync successfully upgraded elsewhere" decision-box, to then take you to either the "join the party" or "Urgent upgrade state" boxes. (If this is correct, could you please upgrade the diagram accordingly? But see also the other item below.) The issue is that the "if sync successfully upgraded elsewhere" decision-box might take a number of seconds to determine. Once the user has explicitly selected the hamburger menu item, I doubt we want to have nothing happen until we can determine if the account has upgraded on another device - but the UX flows don't cover that. It might be as "simple" as the notifications briefly saying "determining your Firefox account status..." or similar. > > "has migration already started on this device?" > > If the user has not reached the "email sent" state, the process starts over > again (I've updated the diagram to reflect this). Can I suggest a couple of changes to the PDF? I think these changes make the flow clearer but don't actually change the intent - if you feel they do change the intent, then we need to chat more :) To the right of the "everyone" arrow there should be a decision box: -> Are we waiting for an account created in a previous session to be verified? Yes: goes directly to the "Pre-Verified state" box on the far-right of the diagram. No: Goes to the next item. The "If server not greenlighting/welcoming upgrades" box should change to a box that says something like "Wait for sync server to notify us of EOL". The "server not greenlighting" and "do nothing" boxes can then be removed - the server will not notify us in that case. The point of this change is to reflect that it is the *server* that initiates the automatic upgrade notifications, not the client - the client isn't going to move past this new box until explicitly invited by the server (which is the key difference to the point above - in that case the user initiated the upgrade and forces us past this "wait for invitation" step.) Also note that in this case, the few seconds it takes to determine the account state, as mentioned above, isn't as much of a concern - the notifications are then being driven by a background process and not in response to a user action - so here we *can* simply wait those few seconds before showing the notification.

I think we can call the UX breakdown "complete" and address other issues we've forgotten as we find them.