1338350 - The first run page needs to know if someone has entered a username or password

Status: RESOLVED FIXED

(Cloud Services :: Server: Firefox Accounts, defect)

Description

[Verdi [:verdi] Best to slack me]

Attachment: skip-setup.png

On the new firstrun page that we built for our onboarding experiment - 
https://www.mozilla.org/en-US/firefox/51.0.1/firstrun/?f=99
https://www.mozilla.org/en-US/firefox/51.0.1/firstrun/?f=100

We've included a skip button. The skip button should get grayed out when someone starts to enter their credentials. Erica (who built the page) said we need a message back from the form in order to make that happen. Without this, we don't know if we can gray out the skip button so it stays active and that leads to a situation where the user could start to sign in or create an account and then choose to "skip the step" that they are on, effectively canceling the operation.

We are about to run a few hundred thousand people through this so we should fix this as soon as possible.

Comment 1

[Ryan Kelly [:rfkelly]]

+Alex for prioritization, +Shane for thoughts on how difficult this might be to add.  I know we log a metrics event for "engaged with the form" but it might not be quite what you want here.

> We are about to run a few hundred thousand people through this so we should fix this as soon as possible.

Can you please say more about your timeline here?  Are you requesting an out-of-cycle deployment of FxA specifically to address this, or can the experiment wait until our next scheduled release in ~ two weeks?

Comment 2

[Ryan Kelly [:rfkelly]]

> The skip button should get grayed out when someone starts to enter their credentials. 

I also wonder whether we could get a similar effect, by having the first-run page detect when the user focus enters the FxA iframe, and grey out the "skip" button at that point.  It might be slightly less nice, but quicker to ship.  (Although I'm not clear on whether inter-frame event permissions allow you to detect that).

Comment 3

[Ryan Kelly [:rfkelly]]

See also mailing-list thread at https://mail.mozilla.org/pipermail/dev-fxacct/2017-February/002249.html

Comment 4

[Verdi [:verdi] Best to slack me]

(In reply to Ryan Kelly [:rfkelly] from comment #1)
> 
> Can you please say more about your timeline here?  Are you requesting an
> out-of-cycle deployment of FxA specifically to address this, or can the
> experiment wait until our next scheduled release in ~ two weeks?

I just sent an email to [e-mail] about this (awaiting moderation). Ideally, we'd need this fix very soon - tomorrow morning California time - to allow for the page to be updated and pushed out. If that's not possible, is there anything sooner than two weeks? We need to run our test for two weeks starting on a Sunday. Waiting two weeks would miss the current window.

Comment 5

[Ryan Kelly [:rfkelly]]

The behavior described in [1] is significantly different to what's requested in this bug, can you please clarify the ask here?  Do you want messages when users starts entering data in the form, or when the form becomes enabled for submission?

[1] https://mail.mozilla.org/pipermail/dev-fxacct/2017-February/002251.html

Comment 6

[Ryan Kelly [:rfkelly]]

> Do you want messages when users starts entering data in the form,
> or when the form becomes enabled for submission?

@erica @verdi and I discussed this in slack and came up with two options, one simpler and one slightly more complex.


The simpler:

Have the FxA iframe send a "submit" message to the parent page whenever the user submits one of our forms.  The parent page would disable the "skip" button when it receives this message, on the assumption that the user is now committed to completing the FxA flow.  Note that this message might come from any of the sign-up, sign-in, or reset-password forms, depending on what the user has been doing inside the iframe.

In this scenario, there's no way for the parent page to re-enable the "skip" button, but that's probably OK as it will avoid most user confusion.


The more complex:

Have the FxA iframe send "enabled" and "disabled" messages to the parent page whenever one of our forms becomes enabled/disabled for submission.  The parent page would disable the "skip" button when the FxA form becomes ready to submit, and re-enable it if the FxA form submit gets disabled.  As above, this would have to be done of any of the sign-up, sign-in, or reset-password forms, depending on what the user has been doing inside the iframe.

This is the preferred option, but only if it's not significantly more complex in implementation.


Shane, you're the best person to judge the relative metrics of the two from the FxA side, thoughts?


> is there anything sooner than two weeks?

If the implementation of one of the above is simple enough, I suggest we target this for a point release of train-80, which is scheduled for deploy next week.  We can do the content-server part of that deploy first in order to get it out sooner.

Another option would be to target the current production train and try to deploy it by end of week.  But we usually reserve the hastily-deploy-on-a-Friday card for e.g. critical security issues, and based on discussion, it sounds like that level of firedrill is not warranted here.

Comment 7

[Alex Davis [:adavis]]

Speaking to :mverdi , he will also check in his meeting tomorrow if the skip button can be gray by default in the first place so that there is no need to listen to our form to change the color of the button. (i.e. always be gray to not have to switch from blue to gray)

I think that if a small UI change can avoid engineering work and a dot release, it would be preferable since this is for an A/B test and it's always best to minimize overhead.

Also, from what I understand, this feature risks postponing the A/B test since the planned UI depends on it so my proposed simple color change to the button could keep everything on track and prevent delays.

Important question to ask: Any risks around changing the button to a permanent gray? Users might think the form is mandatory. However, I think that :mverdi did a good job at cleaning up the copy and since the sign-in form is default here so there should be little to no confusion for the user.

Comment 8

[Ryan Kelly [:rfkelly]]

Noting here for visibility, the requested changes are now ready for deployment as a point release of train-79:

  https://github.com/mozilla/fxa-content-server/releases/tag/v0.79.4

Comment 9

[John Morrison [:jrgm]]

v0.79.4 is now live

{
  "commit": "9c55e3744f9d1cbfd6b19996d2ffe53a795d4035",
  "version": "0.79.4",
  "l10n": "0319b27c74b1d619e2403eafd47c2d19f080c907",
  "tosPp": "22bb005973",
  "source": "git://github.com/mozilla/fxa-content-server.git"
}
{
  "version": "1.79.2",
  "commit": "d86b0517adbdac30cba9f6be867068e340e09206",
  "source": "[e-mail]:mozilla/fxa-auth-server-private.git"
}
{
  "version": "0.79.0",
  "commit": "5c36e2158ff5b36c726d61008c9589f74e1eb8af",
  "source": "git://github.com/mozilla/fxa-oauth-server.git"
}
{
  "version": "0.79.0",
  "commit": "3114531133d20703e532fb7fa275df93e7444f24",
  "source": "https://github.com/mozilla/fxa-profile-server"
}

Comment 10

[Shane Tomlinson [:stomlinson]]

As :jrgm notes above, the content server patch is now live. Thanks :jrgm!