Page MenuHomePhabricator

Use preferences for inputting email address
Closed, ResolvedPublic

Description

We've decided that we're not going to allow inputting email addresses in the help panel. Instead, we're going to link users to their preferences to do it, similarly to how we do in the homepage.

We will wait to tell users about adding/confirming/changing their email preferences until the question has been posted. Having this information before submission is adding a lot of information on the screen that only someone who submits a question needs to know, and is not something that I think really helps push someone to ask a question. These changes are for both desktop and mobile

Here are mockups:

Help panel without email
Posted question - no email
Unconfirmed email
Confirmed email

Here is the specific copy:

  • Posted question - no email
    • "Notifications for your question:"
    • "You'll receive a notification here on Wikipedia once there's a response."
    • "If you'd also like to be notified by email, add an email address now."
  • Unconfirmed email
    • "Notifications for your question:"
    • "You'll receive a notification here on Wikipedia once there's a response."
    • "If you'd also like to be notified by email, confirm your email address now: <email@email.com>"
  • Confirmed email
    • "Notifications for your question:"
    • "You'll receive a notification here on Wikipedia once there's a response."
    • "You'll also receive an email to <email@email.com> (change)"

Event Timeline

This could be the same as / similar to the button in the email submodule of the account module on the home page. Technically that button is just a link, and it links to Special:ChangeEmail (not to preferences).

Cntlsn added a comment.EditedMay 28 2019, 12:17 PM

Below are two mockups designed to allow a user adding or changing their email without the email input field:

  1. Email confirmed state -- link to change email address

  1. No email added state -- link to add an email address

@MMiller_WMF @Catrope Actually there a couple of details for this feature that are not entirely clear to me:

  • the Special:ChangeEmail page is not designed to add a new email, as all the copy in the page is about either changing or removing an email address. I think it could be very misleading to be led to such page after clicking a link that says "Add an email address".
    • shall we change the page copy in case the request is coming from a link to add an email address, or shall we create a new page exclusively for that purpose?
  • after clicking on the "Add an email address" link, the user will leave the editing context, and this could potentially be misleading ("How do I get back?", "Is my draft content saved?"). I have a couple of ideas on how to fix that, but I would have some questions about what is feasible / how it could technically work:
    1. We automatically send them back to the editing context after clicking to submit their email address in the Special:ChangeEmail page.
      • would it possible to go back to the exact same context as the one they left? In the original editing context they potentially have an edit draft and already entered the question in the help panel text field.
        • (if this is possible, then we should notify them of that in the Special:ChangeEmail page, so they know their content is not lost).
      • when back to original editing context, would it be possible to update the email field in the help panel to show the email address they just added?
      • in this scenario they wouldn't have a confirmed email, shall we prompt them to confirm their email by changing help panel copy?
    2. We move to the Special:ChangeEmail page with the help panel still open (and eventually showing the question if it was entered in the original editing context)?
      • after successfully submitting the question, we ask them if they want to go back to the original editing context (this time with the help panel closed).
    3. We never leave the editing context and we show them the same feature we have in the Special:ChangeEmail page in a modal?
      • after successfully submitting the email address, we automatically dismiss the modal and go back to the original editing context with the help panel opened and the email field updated.

Happy to hear your thoughts about this.

kostajh renamed this task from Help panel: use preferences for inputting email address to Use preferences for inputting email address.May 29 2019, 2:19 PM
kostajh updated the task description. (Show Details)

@MMiller_WMF @Catrope
Mockups have been updated in both InVision (https://wikimedia.invisionapp.com/share/KUQV2QDJ8A7#/350626963_Newcomer_Homepage_Contents) and Zeplin also for the "ask a question" modals for both Help and Mentorship modules for both desktop and mobile versions.

The two issues mentioned in the previous comment are also valid for the "ask a question" modals.
In particular:

  • if we lead the user to the Special:ChangeEmail page, can we then send them back to the same state of the Homepage (modal displayed and updated)?
  • on mobile we might have a funny situation where we trigger the "ask a question" modal from a modal (the fullscreen module). If we then lead them to the Special:ChangeEmail page, would it be possible to go back to the "ask a question" modal and then when finished back to fullscreen module?
Cntlsn reassigned this task from Cntlsn to MMiller_WMF.May 30 2019, 3:42 PM
MMiller_WMF reassigned this task from MMiller_WMF to Cntlsn.May 31 2019, 1:12 AM

@Cntlsn and @Catrope -- I think it's good that you identified the two issues of (a) the confusing change email page and (b) the challenge of the user losing their context when they go to add or change their address. Just to make one thing clear, the reason we are changing this email interaction at all is because we need to force users to re-authenticate to change their email address, and Special:ChangeEmail makes users do that (if it's been enough time since they last authenticated). Therefore, any options that have to do with putting the email changing into a modal won't work -- we have to send them to Special:ChangeEmail.

Regarding the confusing nature of the change email page, I agree that it is confusing. It might as well say "Add, change, or remove your email". Like, this problem could be solved with some copy changes. That said, I don't want our team to tackle it now. That is an area of community consultation that we don't have bandwidth for at this time.

Special:ChangeEmail page automatically keeps a "returnto" parameter so that after adding or changing an address, the bottom of the page would say, "Return to Apple" or whatever article they were on, but I don't think that would retain an in-progress edit or keep the help panel open. Therefore, what about these ideas:

  • Opening in a new tab. Help links currently open in a new tab. Why not also open the email settings in a new tab? Perhaps new tabs are more problematic on mobile than on desktop?
  • Moving the email content to after asking a question. Perhaps we could put it on the confirmation screen, which would solve the issue of being taken out of the question-asking context and potentially losing your question. This option doesn't solve the potential for losing an in-progress edit.

I think it would be good for there to be feedback in the help panel that an email address has been changed, but I don't think it's critical.

@Cntlsn -- given all this, what do you think we should do?

@Catrope -- what do you think? Especially about whether someone who goes to Special:ChangeEmail would lose their in-progress edit and help panel question, and about showing feedback in the help panel if someone has added or changed their email?

Cntlsn added a comment.Jun 3 2019, 2:27 PM

@MMiller_WMF

  • Opening in a new tab. Help links currently open in a new tab. Why not also open the email settings in a new tab? Perhaps new tabs are more problematic on mobile than on desktop?

The reason why I didn't propose the new tab behaviour is that it's not a good solution for mobile: closing the just opened tab to go back to the original context is just not straightforward for some users.
It's definitely something we would better test before releasing it, in case we want to proceed this way.

  • Moving the email content to after asking a question. Perhaps we could put it on the confirmation screen, which would solve the issue of being taken out of the question-asking context and potentially losing your question. This option doesn't solve the potential for losing an in-progress edit.

This could be a good compromise, but as you said it won't solve losing an in-progress edit.

I would wait for @Catrope comments before making any decisions here.

Yes, the user will lose their unsaved edit if they navigate to Special:ChangeEmail. Clicking the link would first show them a warning that they're about to lose unsaved content, and they have to click through that to leave the editor and go to Special:ChangeEmail. After they finish changing/setting their email address, they will see a link taking them back to the page they were on (because of returnto, as Marshall said), which will also open the editor again (because of returntoquery, which will be set to action=edit or something similar). I believe VisualEditor will recover the unsaved change in this case, but despite that I think that making the user navigate away during an edit session is bad and we should avoid it.

As Marshall said, if we put a change/set email link in the confirmation screen, we don't have to worry about losing the question, so that would be enough to address this issue for the help module and mentorship module on the homepage, and for the help panel in read mode, but not for the help panel in edit mode. Marshall is right that inlining ChangeEmail in the help panel is hard (and possibly a bad idea) because of the reauth prompt. The best option I can think of is to open a new tab, or a new window (limited to when it's needed, i.e. only for the help panel in edit mode). We could explore using window.open() to programmatically open a new window, then programmatically close it again once they're done (this is how "log in with Google/Facebook/whatever" buttons work on many web sites). There may be other solutions; I'll ask Kosta and Stephane to weigh in on this task, maybe they'll have better ideas.

If we come up with a solution that works, we could also consider adding two email links to the ask-a-question flow: one before submission as currently designed (which would always open a new tab/window, or whatever other solution we come up with), and another one in the confirmation screen (which would navigate away if possible, and open a new tab/window otherwise).

As for Special:ChangeEmail being confusing: you're right that it's confusing and badly designed, and I'd be happy for us to make improvements to it (to the page itself, not part of our experiments). But as Marshall said that would also take a little bit of community consultation work (not much though, it's a pretty minor/niche thing).

Cntlsn added a comment.Jun 6 2019, 3:45 PM

Thanks a lot @Catrope for making some clarity on this!

Considering the previous comments, here is what I think would be our best option:

  1. move the add/change email address link to the success screen of the "ask a question" process, in all of its instances (help panel, help and mentorship modules) *
  2. open Special:ChangeEmail in the same tab if the user is coming from the help or mentorship module context
    • In this scenario the link in the Special:ChangeEmail final screen would link back to the Homepage
  3. open Special:ChangeEmail in a new tab if the user is coming from the help panel
    • In this scenario the link in the Special:ChangeEmail final screen would close the tab and say something like "Close and go back to the editor"

* Here is how the screens of the "ask a question" process would look like if moving the link to add/change email to the last screen (the help panel will receive the same design treatment):

About the treatment for the Special:ChangeEmail page I think it would mostly be copy changes, plus I would suggest to add buttons instead of links in the last screen to go back to the context of origin.

@MMiller_WMF thoughts?

MMiller_WMF added a comment.EditedJun 7 2019, 9:52 PM

@Cntlsn -- I think this plan sounds good, except the one concern I have is how moving the email content to the confirmation screen will affect the user's understanding of how question-asking will work (like is discussed in T223189). For instance, is it important to tell the user early on how they will receive the response? Is there a way to tell them without raising the question of what their email address is and how to change?

For our reference, these are the states of the panel for three states of the email address:

No email:

Unconfirmed:

Confirmed:

@MMiller_WMF
I did some thinking about this, and my conclusions are that if our goal is to push more users to conclude the process and submit their questions, I agree that we would need to give the right (and right amount) of information before they push the "post my question" button, but also minimize the opportunities of leaving the flow mid-way (for instance by offering links to other places)

According to this I have:

  • designed a new version that gives the user more information about how they will get notified of responses.
  • left the add/change email link to the success screen.
  • taken the opportunity to clean-up the copy a little bit and try to convey the same information minimizing redundancy.

Ask a question screen

  • The text explaining the "Ask a question" process has been modified to avoid the use of the genderless pronoun "they", which despite always being a preference for matter of inclusion, in this scenario could lead to the confusion whether the talk page is of the user's mentor, or potentially other talk pages of other people. The text would read: "When you ask a question, it gets posted publicly under your username, “NewToWiki”, to your mentor’s talk page, where your mentor will answer to it."
  • A copy of the "Your notices" icon has been added below the textbox to invite the user make the association between the icon and the place where they will receive the notification about the response. A text accompanies the icon reading: "You will receive a notification when your question has been responded to, likely within a day or so."
  • An email icon has also been added below with accompanying text to inform the user about the possibility of receiving an email notification: "If you wish to also receive an email, you will find a link to add or modify your email address in the next screen."

Success screen

  • Copy has been cleaned-up to minimize redundancy
  • A link to the Special:ChangeEmail page is presented, accompanying text is not informing the user about the email confirmation as that copy should be moved (if not already present) in the Special:ChangeEmail page

No email added


Confirmed email

I have a couple of questions about the Unconfirmed email state:

  • if the user email is not confirmed, will the user receive an email notification that the question has been responded to anyway?
  • from what I understand of the previous version of the module, the confirmation email was triggered by the "post my question" button. But now that we're gonna send the user to the Special:ChangeEmail page, where all the email operations will be processed, I think all the info related to the confirmation email should live in the Special:ChangeEmail page. What do you think?
JTannerWMF added a comment.EditedJun 12 2019, 1:40 AM

I recommend adding checkboxes for tasks like these where two modules and platforms will need this implementation

Ex

  • Mentorshp Module Desktop
  • Help Module Desktop
  • Help Module Mobile
  • Mentorship Module Mobile

If multiple Engineers would like to merge patches Agile instead of waterfall they can break these into subtasks.

JTannerWMF moved this task from Needs triage to Triaged on the Mobile board.Jun 12 2019, 1:40 AM
Cntlsn updated the task description. (Show Details)Jun 12 2019, 6:00 AM
Cntlsn updated the task description. (Show Details)
Cntlsn updated the task description. (Show Details)

The next step is for me to write the copy for the new designs.

Cntlsn reassigned this task from Cntlsn to MMiller_WMF.Jul 3 2019, 4:35 PM

One of the things we need to think about is which (if any) of the new gray notices at the bottom of the window appear for users who already have a confirmed email, or already have an unconfirmed email.

Thanks @MMiller_WMF, the first one of the mockups above is showing a scenario where a user didn't confirm an email and is posting a question for the first time, but actually the area below the text box can be used to show notices tailored around user type.
As you pointed out, in the scenario of asking a question the two main characteristics that would make a user different are whether the user have added and confirmed their email, and if it is the first time the user is posting a question (and so it hasn't received the guided tour suggesting where to look for answers yet).
Depending on the user type I think we would change the copy, but the layout and icons should work as is.

Scenario A - User didn't add email

  • "If you wish to also receive an email, you will find a link to add your email address in the next screen."

Scenario B - User didn't confirm email

  • "It looks like your email address has not been confirmed yet. If you wish to receive an email when your answer has been responded to you can confirm your email address in the next screen."

Scenario C - User confirmed email

  • "You will also receive an email when your question has been responded to. You can change this preference in the next screen."
  • Eventually this last notice can be removed after a number of visits.

I think the first one of the two notices, indicating where to go check for notifications, should stay there in all scenarios. If it's true that it could be redundant with guided tour showing up after posting the first question, it's also true that it's not particularly intrusive while still a helpful reminder for newcomers.

Happy to hear your thoughts about it!

MMiller_WMF added a comment.EditedSep 11 2019, 12:17 AM

@RHo and I have to discuss this, since we're committed to addressing it. I've put it on our agenda to discuss.

RHo added a comment.Sep 17 2019, 1:00 PM

Thinking about this a bit more, I propose we tell users about adding/confirming/changing their email preferences until the question has been posted. Having this information before submission is adding a lot of information on the screen that only someone who submits a question needs to know, and is not something that I think really helps push someone to ask a question.

Help panel without email
Posted question - no email
Unconfirmed email
Confirmed email
MMiller_WMF updated the task description. (Show Details)Sep 17 2019, 5:40 PM
MMiller_WMF removed a project: Growth Design.

This is ready to be worked on, but I'm putting it into "Incoming" so we can triage it onto the sprint board at our next team meeting.

@RHo -- is going to upload one more correction on the mockups.

MMiller_WMF removed MMiller_WMF as the assignee of this task.Sep 17 2019, 5:42 PM
RHo updated the task description. (Show Details)Sep 17 2019, 6:03 PM
RHo updated the task description. (Show Details)
RHo added a comment.Sep 17 2019, 6:55 PM

This is ready to be worked on, but I'm putting it into "Incoming" so we can triage it onto the sprint board at our next team meeting.

@RHo -- is going to upload one more correction on the mockups.

Updated!
Also: I did not include mocks for the "Ask a mentor" screens in the homepage since it is the same changes, but can add some if deemed useful during triage.

Tgr claimed this task.Sep 26 2019, 7:10 PM
Tgr added a comment.Sep 29 2019, 6:12 PM

It would be more accurate for the email confirmation button to say something like "Resend confirmation email" than "Confirm your email".

(Right, and "Confirm your email" makes no sense - "Confirm your email address" would...)

Tgr added a comment.Sep 30 2019, 9:41 AM

The task description didn't specify, but I'm assuming the email-related functionality in ApiHelpPanelPostQuestion has to be removed as well as nothing else uses it (and the old behavior of automatically sending a confirmation email if the user posted a question while unconfirmed doesn't make sense now that we show an email resend button after posting).

Change 539870 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] QuestionPoster: do not ask for email address

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

The task description didn't specify, but I'm assuming the email-related functionality in ApiHelpPanelPostQuestion has to be removed as well as nothing else uses it (and the old behavior of automatically sending a confirmation email if the user posted a question while unconfirmed doesn't make sense now that we show an email resend button after posting).

Yes, that is exactly what I wanted to happen, thanks for going ahead and doing it. Sorry that it wasn't spelled out more clearly.

Tgr added a comment.Oct 1 2019, 12:03 PM

Technically the API change is a B/C break, I'll announce on wikitech-l once it is merged.

@nettrom_WMF heads up that with this change for the HelpPanel schema with action=link-click some of the action_data values change: special-notifications has been removed (we don't link to it anymore), special-change-email has been added (the button on the second mockup and the link on the fourth one) and special-confirm-email is now a button (on the third mockup) instead of a plain link.

Change 539870 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] QuestionPoster: do not ask for email address

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

@Tgr -- thanks for pointing out the changes to EventLogging. I just checked my reporting code, and those won't affect my reports, so we're good there.

@Tgr : likewise, thanks for letting me know about these changes. I don't have any current analysis or reporting that will be affected, so we're good there as well. (My main concern was Marshall's reports, but since he already checked those all is well)

For Design Review
To summarize

  • Users would add/confirm/change their email preferences after the question was posted.
  • Clicking on 'Add email' and 'Confirm your email' will open a tab with

https://en.wikipedia.beta.wmflabs.org/wiki/Special:ChangeEmail and https://en.wikipedia.beta.wmflabs.org/wiki/Special:ConfirmEmail respectively.

  • the only point of confusion may be when Special:ConfirmEmail asks to re-send confirmation code which users may be tempted to click (which is not actually an issue)

The screenshots (in case, @RHo could spot something amiss):

Posted question (no emailUnconfirmed emailConfirmed email
MMiller_WMF reassigned this task from Tgr to RHo.Oct 3 2019, 12:04 AM
MMiller_WMF added a subscriber: Tgr.

Updates LGTM thanks

MMiller_WMF closed this task as Resolved.Oct 4 2019, 1:22 AM

I tested it out, and I think it looks good. Thank you!

Urbanecm edited subscribers, added: Urbanecm_WMF; removed: Urbanecm.Aug 26 2020, 1:52 PM