User is able to enter an email address in new onboarding tour even after the user has already signed into Sync.

NEW
Unassigned

Status

()

defect
P5
normal
2 years ago
2 years ago

People

(Reporter: stomlinson, Unassigned)

Tracking

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 wontfix)

Details

(Whiteboard: [photon-onboarding])

Attachments

(1 attachment, 1 obsolete attachment)

STR

1. With a new profile, open the new onboarding tour.
2. Click on the "Sync" tab.
3. Enter an email address, click "Next".
4. On FxA, complete signin/signup process, including opening any verification links.
5. Open a new tab, open the new onboarding tour. A green checkbox appears next to Sync.
6. Click on the Sync tab.
7. Even though the user is already signed into Sync, they are able to enter a different email address.
8. Entering in an email address takes the user to "about:accounts" where "Sync Preferences" is displayed.

Expected

User should be unable to enter a different email address. I don't know what the UX *should* be, but entering a different email address seems incorrect to me.

Actual

User is able to enter a different email address, which causes subsequent strangeness.

Updated

2 years ago
Whiteboard: [photon-onboarding][triage]
As I know this behavior is by design, since in step 6~8 the user can check he is already signin.

Updated

2 years ago
Depends on: 1357023
Reporter

Comment 2

2 years ago
(In reply to Fred Lin [:gasolin] from comment #1)
> As I know this behavior is by design, since in step 6~8 the user can check
> he is already signin.

Will this onboarding tour only be displayed once? If so, we can close this issue
as INVALID because a user will only be able to enter an email a single time. 
Otherwise, I disagree with the current approach and think we can do better.

Sure, the user can check whether they are signed in, 
but that shifts the onus onto them when we already have the knowledge to 
handle this case cleanly.

Encouraging users to sign into Sync when they have already done so is a 
recipe for confusion. Signed in users that enter an email address and click
"Next" aren't even displayed FxA's signin page. Instead, about:accounts 
is opened and a big button to "Sync Preferences" is displayed. Clicking 
"Sync preferences" opens about:preferences#sync; there is no way for 
the user to sign in using the just entered email address.

AFAIK, privileged contexts are able to query whether a user is signed into Sync.
If we have access to the knowledge ourselves, we should be able to handle
this case gracefully - in the "Sync" pane of the onboarding tour, instead
of showing a form field with an email address, we could, e.g., show the user's 
FxA display name and email address.

Updated

2 years ago
Component: General → New Tab Page
This is by design, set it P3
Status: NEW → UNCONFIRMED
Ever confirmed: false
Priority: -- → P3
Whiteboard: [photon-onboarding][triage] → [photon-onboarding]
Yes we should show different content here. Originally, this wasn't a problem because our plan was to iframe in the sign up form. That would have shown the user as signed in when the flow was complete. Since we can't do that and we've come up with this other solution, we no longer get that benefit. We'll have to figure out what to show here. Maybe we can give you a virtual high-five.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Tim, as a first step, for users who have enabled Sync, please simply remove the Create a Firefox form (title, field, etc).

I will design a screen in a new bug.

Make sense?
Flags: needinfo?(timdream)
Bug 1357027 will expose Sync sign-in state to the onboarding overlay. So at least that half is done. There is no need to file another bug, but please understand both this bug and bug 1357027 was demoted to P3 so we could complete the feature in time, so there is no promise that this will make into 56.

Rex, could you follow this up with Ryan? Let's make this top-most-painful-need-to-fix-first P3 :)
Depends on: 1357027
Flags: needinfo?(timdream) → needinfo?(rexboy)
PS for this bug to work as intented, it also means we'll need to stop marking the tour as completed as soon as the user hitting the submit button on the sign-up form. This is not done in bug 1357027 so it should be done here (along with the updated design).
I'm fine to have it implemented. But I'm not sure if removing the form without any description makes less confusion.
All the login check needed has been done in bug 1357027 and we just need a spec to move on. If you can make the design maybe you could send the UI-review to Verdi?
Flags: needinfo?(rexboy)
Posted image sync-configured.gif (obsolete) —
To at least get rid of the footgun we have today, can we do something like this? (animation, 2 frames, 1 second each showing sync not enabled, and enabled)
Flags: needinfo?(timdream)
Flags: needinfo?(rexboy)
Look good to me but I am not qualified to approve designs :) If we could get a string to congratulate user that would be better; we could use the same layout as bug 1374717 (which shows a similar string when we are already the default browser.)
Flags: needinfo?(timdream)
Flags: needinfo?(rexboy)
Flags: needinfo?(mverdi)
Tim: Because Sync requires more than one device to work fully, we would likely mirror the functionality on this page (a small congratulations, but a suggestion that they keep adding devices).

Something like this page: https://accounts.firefox.com/connect_another_device?service=sync

I'll be working on it and reviewing with Michael.
Shane & Tim - how will the tour know if you have indeed created an account and confirmed it? I thought we wouldn't be able to do this check in time for 57. That leads me to think this will just remove the form if someone uses it once to start the process and then it's gone whether or not they complete. Is that right?
Flags: needinfo?(mverdi) → needinfo?(timdream)
Hi Verdi and Ryan,

Please consider the following case, thanks:
1. User signed into the Fx account and got verified and not yet entered the sync tour before.
2. In the background, the onboarding would make the Sync tour as completed and enter the ACCOUNT_WORK_DONE state: the email form is hidden and some strings are added. (Assume we judge on the account verified for example)
3. User entered the Sync tour, seeing the tours is completed and the ACCOUNT_WORK_DONE state.
4. User entered about:preferences and signed out from the Fx account for any reason.
5. User entered the Sync tour again. The sync tour is completed still.
6. For the email form, should we (a) still keep the ACCOUNT_WORK_DONE state or (b) back to the state before the ACCOUNT_WORK_DONE state or ?
Flags: needinfo?(rfeeley)
Flags: needinfo?(mverdi)
I believe what we have talked about during the meeting was:

1. Keep the two state ("tour complete/check mark state" and "sync tour view/show-email-form state") distant.
2. There will only be two states for each: tour completed or incomplete, show e-mail form or show a completed copy instead.
3. Tour is considered complete whenever
3.1 The user has view the tour (a bug was filed)
3.2 The user has set up sync completedly, including verifying email
4. The e-mail form should be replaced with a completed copy when
4.1 The user has set up sync completedly, including verifying email (this is align with 3.2)

I hope this can be updated in a canonical spec, but we don't have that to begin with so let's don't worry about it. We should improve that in the future.
Flags: needinfo?(timdream)
For comment 13 which is the case where the user have signed in *and* signed out of the sync, my suggestion is to leave the tour in a completed state while keep the email form visible. That means a new rule 3.3 needs to be added into comment 14:

3.3 Rule 3.2 had ever been fulfilled before.

That will save as some trouble to keep the state 3.1 seperately. We will need to keep state 3.1 presistent to tell if we want to revert state 3 or not because we don't know if the user has reached 3 because of 3.1 or 3.2...
(In reply to Tim Guan-tin Chien [:timdream] (please needinfo) from comment #14)
> I believe what we have talked about during the meeting was:
> 
> 1. Keep the two state ("tour complete/check mark state" and "sync tour
> view/show-email-form state") distant.
> 2. There will only be two states for each: tour completed or incomplete,
> show e-mail form or show a completed copy instead.
> 3. Tour is considered complete whenever
> 3.1 The user has view the tour (a bug was filed)
This has been implemented in bug 1381407.
> 3.2 The user has set up sync completedly, including verifying email
> 3.3 Rule 3.2 had ever been fulfilled before.
in bug 1357027 we set tour to complete if they logged in, or is in login state from startup. So these should satisfy 3.2 and 3.3.
> 4. The e-mail form should be replaced with a completed copy when
> 4.1 The user has set up sync completedly, including verifying email (this is
> align with 3.2)
I think there's a choice that we show the form only if a user is not logged in.
(AFAIK this should need an async message though because FxAccounts.jsm can be loaded only from chrome process)

> 
> I hope this can be updated in a canonical spec, but we don't have that to
> begin with so let's don't worry about it. We should improve that in the
> future.
Posted image sync-signed-in.png
Here's what I'd like to do:

* If the user gets to the sync section of the tour and IS NOT SIGNED IN, we should mark the tour complete upon viewing the panel. Then if they create an account (whether or not they verify their account) we replace the tour panel with the attached version.

* If the user is ALREADY SIGNED IN before they view the sync panel it should already be marked as complete and we should only show them this new version of the panel.

Here is the approved copy for the panel:
Headline: You’re signed in to Sync!
Body: Sync works when you’re signed in to Firefox on more than one device. Have a mobile device? Install the Firefox app and sign in to get your bookmarks, history, and passwords on the go.

I'm not sure how we've included app store badges in other web pages but Apple and Google pages about them are here:
https://developer.apple.com/app-store/marketing/guidelines/#downloadOnAppstore
https://play.google.com/intl/en_us/badges/
Attachment #8886669 - Attachment is obsolete: true
Flags: needinfo?(mverdi)
Those icons are included on FxA servers. See bug 1149685.
The icons are done with different language versions, and different device pixels. (@2x version)

available icon languages are written in server-side:
https://github.com/mozilla/fxa-content-server/blob/8f1ddd14112d8e30465a9302b29dc4d4c5ad0070/app/scripts/views/marketing_snippet.js#L35

Technically we can do either:
- Put all the icons on FxA server in Firefox. 
- Or just load icons from FxA server. Maybe include just a fallback English icon in Firefox.

But my question is, should we double confirm with legal & market for including these store icons before doing?
(In reply to Verdi [:verdi] from comment #17)
> * If the user gets to the sync section of the tour and IS NOT SIGNED IN, we
> should mark the tour complete upon viewing the panel. Then if they create an
> account (whether or not they verify their account) we replace the tour panel
> with the attached version.

Just curious, are all the tour sections marked as completed when viewed? Or do some of them require action?


(In reply to KM Lee [:rexboy] from comment #18)
> Technically we can do either:
> - Put all the icons on FxA server in Firefox. 
> - Or just load icons from FxA server. Maybe include just a fallback English
> icon in Firefox.

Mozilla.org and FxA host the buttons themselves (last I heard). It gives us more control and we use our own tracking with them, not sure there was a legal reason.
(In reply to Alex Davis [:adavis] [PM FxA+Sync] from comment #19)
> (In reply to Verdi [:verdi] from comment #17)
> > * If the user gets to the sync section of the tour and IS NOT SIGNED IN, we
> > should mark the tour complete upon viewing the panel. Then if they create an
> > account (whether or not they verify their account) we replace the tour panel
> > with the attached version.
> 
> Just curious, are all the tour sections marked as completed when viewed? Or do some of them require action?
> 
Some requires action.
> 
> (In reply to KM Lee [:rexboy] from comment #18)
> > Technically we can do either:
> > - Put all the icons on FxA server in Firefox. 
> > - Or just load icons from FxA server. Maybe include just a fallback English
> > icon in Firefox.
> 
> Mozilla.org and FxA host the buttons themselves (last I heard). It gives us more control and we use our own tracking with them, not sure there was a legal reason.
Looked into the App Store[1] and the Play Store[2] badge usage requirements. It seems fine.

Except that the Play Store says a review is required if "a marketing campaign that will receive over 1 million impressions".
What we do is the onboarding tour, probably not belonging to "marketing campaign".

[1] https://developer.apple.com/app-store/marketing/guidelines/#overview
[2] https://play.google.com/intl/en_us/badges/
It just occurred to me: how are we going to localize these images in Firefox? I don't think such process exists...
Flags: needinfo?(francesco.lodolo)
There is no process to ship localized images in Firefox, we have never done anything like that.
Flags: needinfo?(francesco.lodolo)
(In reply to Francesco Lodolo [:flod] from comment #22)
> There is no process to ship localized images in Firefox, we have never done
> anything like that.

Thanks for the quick reply.

:'(

Anyway, we talked about this offline and we agreed we should ship the feature without the store badges first. Rex is going to file another bug to get that landed so we can keep the badge discussions here.
Flags: needinfo?(rexboy)
Bug 1384045 opened.

To be clear, we already have localized icon sets from Apple and Google. We don't need to do l10n by ourselves.
I can propose to include these pictures somewhere in the source tree, and read navigator.language and window.devicePixelRatio to put on the correct one. If we don't have process to ship icons from the source tree, we can just load them from FxA's server instead. That way users need to be online to see those icons though.
Flags: needinfo?(rexboy)
> To be clear, we already have localized icon sets from Apple and Google. We don't need to do l10n by ourselves.

Yes, but Apple Store and Google Play Store has different set of locales they support than Firefox. It's not one-to-one mapping.
Priority: P3 → P5
Flags: needinfo?(rfeeley)
You need to log in before you can comment on or make changes to this bug.