@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.

In T211113#4803583, @kostajh wrote:

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?

In T211113#4804178, @kostajh wrote:

@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.

In T211113#4804197, @RHo wrote:

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.

In T211113#4806078, @kostajh wrote:

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.

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

@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.

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.

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

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..."

In T211113#4850588, @MMiller_WMF wrote:

@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