bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

[UX] UX for Sync Migration while migration is in progress

RESOLVED FIXED

Status

()

Firefox
Sync
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: markh, Assigned: fang)

Tracking

unspecified
Points:
13
Dependency tree / graph
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ux])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
This bug is to breakdown the UX for the sync migration *during the migration* - ie, once the user has opted to begin.

Specifically, part of the migration process will require the user to create a FxA account and wait for verification.  While we can open about:accounts to begin this process, we can't force the user to complete the process, and have no control over how long the notification email takes to arrive (if it arrives at all).

Note that the browser might exit during this process - the browser could crash, the user could accept an upgrade notification, or the user may simply forget what they were doing.

With the current thinking, the primary states the migration will be in are:

* Offer accepted, waiting for signin to FxA account.
    We can open about:accounts, but must wait for the uer.

* Signed in to FxA account, but waiting for it to be verified.
    We can't really do anything to help this along other than remind
    the user we are waiting.

* Account verified, but waiting for us to upload the FxA account name for migration on subsequent devices.
    This doesn't require user interaction, but will depend on the 
    state of the network and even our Sync infrastructure.

* Waiting for the first FxA sync to complete
    Although once we are in this state we are effectively complete, so
    there may be no need to have any special UX in this state.
For new Sync.FxA registrants, we display an unverified state (really more of a pre-verified state):

https://www.dropbox.com/s/gbhdffre8ztefq9/Desktop%20-%20Preferences%20-%20Sync%20-%20Unverified.pdf

For migrating users, there is already syncing in place (legacy sync, see attached)

Would we “freeze” legacy sync until the account is verified? (forcing them into the new sync?) If so, the Sync.FxA PDf above is probably all we need.

Or would we allow the user to cancel/back out of the upgrade? 

If yes, the only change we'd need to make is to replace "Forget this email" with "Cancel", reverting to the old sync state.

Thoughts?
Created attachment 8432527 [details]
old-sync.png
(Reporter)

Comment 3

4 years ago
The way I was thinking, and reading the PDF from bug 1014412, the sync dialog doesn't seem to come into it.

IIUC, it looks something like:

* An infobar tells the user they can upgrade, with a button to "join the party" (as the PDF puts it).

* We then display about:accounts with the form filled with their email address

Note that at this point we have a tab with about:accounts - no sync dialog.  We are waiting for the user to perform the login.

What UI is shown at this point?  I was assuming the infobar would remain, but indicating something like "To continue upgrading sync, please login or create an FxA account".  Note that at this point the user might close the browser (or it might crash).  In that case, upon next startup we'd eventually get the new EOL notification from Sync - but instead of starting again, I'd assume the infobar goes back to where it was - "To continue upgrading sync, please login..." - presumably we'd them want a button to re-open about:accounts, and the infobar again stays open.

* At some point the user then creates an account, but is waiting for verification

At this point I'd assume the info bar remains, but now says "To continue upgrading sync, please check your email for a verification mail, and click the link".  Again, at this point the browser might stop, and again, on restart we'd eventually want the infobar to reopen in the exact same state (ie, we don't want to reset and ask them to log back in - they already *are* logged in, just not verified)

* Finally the user verifies, and we can finish the sync.

At this point the infobar would probably say "Please wait while we complete the sync upgrade", and eventually the "now syncing" panel would open.  The migration is now complete.

At no point the Sync "options" pane opened.

Obviously I might be missing something, but the above reflects my understanding of the general outline from bug 1014412.
I will flesh out the migration plan on Monday so it's ready for consumption into the cycle next week.

Here is where we're at (LucidChart is back online).

https://www.lucidchart.com/documents/view/e437f157-365a-4bdc-8f49-d76007559aa8
Adding myself to cc list because I suspect I'm going to wind up being the one to test all of this.  Also taking QA Contact.

Ryan et al, can we set up some time early next week to go over how you envision testing this stuff?
QA Contact: kthiessen
This is a UX bug, so there will be no output to test here - testing will need to occur in associated implementation bugs (e.g. bug 1019985 and related bugs).

Updated

4 years ago
Flags: firefox-backlog+
Whiteboard: p=0 [qa?]

Updated

4 years ago
Summary: UX for Sync Migration while migration is in progress → [UX] UX for Sync Migration while migration is in progress
Whiteboard: p=0 [qa?] → [ux] p=0 [qa-]

Updated

4 years ago
Whiteboard: [ux] p=0 [qa-] → [ux] p=13 [qa-]
Added to Iteration 33.1
Assignee: nobody → zfang
Status: NEW → ASSIGNED
Whiteboard: [ux] p=13 [qa-] → [ux] p=13 s=33.1 [qa-]

Updated

4 years ago
Iteration: --- → 33.2
Points: --- → 13
QA Whiteboard: [qa-]
Whiteboard: [ux] p=13 s=33.1 [qa-] → [ux]

Updated

4 years ago
Iteration: 33.2 → 33.3
Blocks: 1038805
Here is the most recent UX flow: https://www.lucidchart.com/publicSegments/view/53960efc-4b5c-484a-bcd5-13930a00de31/image.pdf
The followup engineering bug: Bug 1038805
No longer blocks: 1038805
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Blocks: 1038805

Updated

4 years ago
Depends on: 1091815
QA Contact: kthiessen
You need to log in before you can comment on or make changes to this bug.