Page MenuHomePhabricator

Help panel: allow users to supply an email address
Closed, ResolvedPublic

Description

Mockup: https://wikimedia.invisionapp.com/share/XSP2H5Z7ZMY#/screens/330925613

  1. If the user does not have an email address, the question review step will have an empty box for adding it, labeled "Email address (optional). If they enter an email address, it will become the email address for their account, and they will receive a verification email after submitting their question.
  2. If the user has an email address but it is not verified, the question review step will have an editable box pre-populated with the user's email, labeled "Email address (optional)". If they enter an email address, they will receive a verification email after submitting their question. If they delete their email address, it will delete the email for their account.
  3. If the user has a verified email address, the question review step will have their email address, uneditable, labeled "Email".

Each of those three scenarios will have a different "Note" explaining the scenario.

Event Timeline

kostajh created this task.Dec 4 2018, 2:24 PM
kostajh removed a project: Epic.Dec 4 2018, 2:57 PM
kostajh edited projects, added Growth-Team (Current Sprint); removed Growth-Team.
MMiller_WMF renamed this task from Allow users to supply an email address via the help panel to Help panel: allow users to supply an email address.EditedDec 4 2018, 10:42 PM

@kostajh @RHo -- that second rule, to encourage the user to verify their email address, is something we haven't discussed. How were you thinking that would work? Should they re-enter their email so that they get the verification sent again?

I think the best would be to provide a link to wiki/Special:ConfirmEmail, where the user can follow the instructions to mail themselves a new verification code.

RHo added a comment.Dec 6 2018, 7:15 PM

I think the best would be to provide a link to wiki/Special:ConfirmEmail, where the user can follow the instructions to mail themselves a new verification code.

Can we allow them to confirm their email address directly from the form instead underneath where the email is displayed? Similar to how unconfirmed emails are shown in user preferences:
User prefs example:

Proposed confirmation:

@RHo what should the "Confirm your email" button do? In preferences, it takes you to /wiki/Special:ConfirmEmail. Would the button in the help panel do the same thing or do you want that button to trigger sending the confirmation email, then disable the "Confirm your email" button and add text explaining to the user that they should check their inbox and click the link to confirm their email?

RHo added a comment.Dec 6 2018, 7:24 PM

@RHo what should the "Confirm your email" button do? In preferences, it takes you to /wiki/Special:ConfirmEmail. Would the button in the help panel do the same thing or do you want that button to trigger sending the confirmation email, then disable the "Confirm your email" button and add text explaining to the user that they should check their inbox and click the link to confirm their email?

Seems more straightforward that it takes users to the /wiki/Special:ConfirmEmail page.

Seems more straightforward that it takes users to the /wiki/Special:ConfirmEmail page.

It would require to open a new tab. I hope that those users wouldn't be lost by that action.

Here's what this looks like:

I'm wondering what you think about moving the "Confirm email" note and step to the last panel. My reasoning is:

  1. Suppose the user clicks "Confirm email"
  2. Special:ConfirmEmail will open for them in a new tab or window. Best case scenario, they'll click the "mail link", go to their inbox, click the link, and be back on Special:ConfirmEmail with a notice that their email was confirmed.
  3. Then, they'll have to find their other tab/window with the help panel. Once there, they'll still see "Confirm your email". We could make "Confirm your email" disabled as soon as the user clicks it, but then it's still potentially confusing to the user as to whether they succeeded in confirming or not.

If we move the "confirm your email" flow to the last step of the panel, there's less chance of the user getting confused about what's going on, IMO.

RHo added a comment.Dec 7 2018, 3:53 PM

Here's what this looks like:

I'm wondering what you think about moving the "Confirm email" note and step to the last panel. My reasoning is:

  1. Suppose the user clicks "Confirm email"
  2. Special:ConfirmEmail will open for them in a new tab or window. Best case scenario, they'll click the "mail link", go to their inbox, click the link, and be back on Special:ConfirmEmail with a notice that their email was confirmed.
  3. Then, they'll have to find their other tab/window with the help panel. Once there, they'll still see "Confirm your email". We could make "Confirm your email" disabled as soon as the user clicks it, but then it's still potentially confusing to the user as to whether they succeeded in confirming or not.

    If we move the "confirm your email" flow to the last step of the panel, there's less chance of the user getting confused about what's going on, IMO.

Counter-proposal:
Can we do the work for the user and just send the confirmation email to the email address if they proceed with submitting a question?
Like so:

I like that idea. @MMiller_WMF please let me know when this is finalized.

kostajh added a comment.EditedDec 7 2018, 6:12 PM

Per feedback from @RHo I went ahead with the proposal from T211113#4806183

Here are screenshots of what this looks like:

No email:

Confirmed email

Unconfirmed email

@RHo @MMiller_WMF I'm a little concerned about the proportion of non essential text to the primary goal of this tool (allowing the user to ask a question). As you can see, the question input is now about 1/5 of the total content of the panel and is the next to last element in the panel. We should discuss in another task, but perhaps we could consider removing username/email (for all statuses) and remove the "Note" for users who have confirmed email addresses.

Change 478231 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Help Panel: UI updates for different email statuses

https://gerrit.wikimedia.org/r/478231

MMiller_WMF added a comment.EditedDec 7 2018, 7:40 PM

@kostajh, @RHo, and I settled on a plan here.

  • There will be three states, as @kostajh shows in three screens above.
  • Each state will have a different message under the email field, with users who do not have a confirmed email being told that they will receive a confirmation email by submitting their question.
  • If a user has an email address, but it is not confirmed, it will be prepopulated in an editable field, under an "Email (optional)" label.
  • To save space on the page, the username is going to move up into the first paragraph, and we'll remove the labeled field.

I will now add these requirements to this tasks's description.

@RHo will add mockups for the three scenarios.

MMiller_WMF updated the task description. (Show Details)Dec 7 2018, 7:44 PM

Change 478231 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Help Panel: UI updates for different email statuses

https://gerrit.wikimedia.org/r/478231

The UI can be QA'ed, but the behavior (setting email, sending confirmation email) won't work until T211370 is merged.

T211370 is merged, but the functionality doesn't work properly on beta labs. Moving this task back into ready-for-development, to ensure that the backend logic is fixed.

T211370 is merged, but the functionality doesn't work properly on beta labs. Moving this task back into ready-for-development, to ensure that the backend logic is fixed.

Actually, not sure if email works at all on beta labs. It doesn't appear to, anyway. I'm moving this back into QA, and when help panel is enabled on test wiki (I'm proposing December 18 for that), we can QA there.

MMiller_WMF updated the task description. (Show Details)Dec 18 2018, 9:53 PM

All functionality of sending/changing email addresses has been checked in testwiki.

The states of an email address - not entered, unconfirmed, and confirmed - are illustrated below (the screenshots are taken from betalabs).

No email - the email field is
empty


Unconfirmed email

Confirmed email

@Etonkovidova -- the testing was done on testwiki but the screenshots are from beta? Something I noticed is that the message for "no email" is incorrect. It is supposed to start with "If you add an email address to your account..." not "You'll receive..."

RHo added a comment.Jan 3 2019, 7:41 PM

@Etonkovidova -- the testing was done on testwiki but the screenshots are from beta? Something I noticed is that the message for "no email" is incorrect. It is supposed to start with "If you add an email address to your account..." not "You'll receive..."

Testing on Beta labs since it sounds like not everything is merged on Testwiki yet, and I am getting the correct message for no email as well as unconfirmed and confirmed email scenarios:

No email
Unconfirmed email
MMiller_WMF closed this task as Resolved.Jan 15 2019, 12:40 AM
MMiller_WMF moved this task from Needs PM Review to Done on the Growth-Team (Current Sprint) board.

I tested this in production on Czech (we can't create accounts in Korean from outside Korea right now), and things were behaving as expected.