Page MenuHomePhabricator

Homepage: allow users to remove the startemail module from the homepage once their email is confirmed
Open, MediumPublic

Description

This task relates to T260780 as it pertains to changing the prominence of the startemail module depending on whether a user has added and verified their email address. We want to give users the option of removing the module to show the Suggested edits module more prominently once their email address has been added, especially as the startemail module is no longer actionable or useful after the email is confirmed.

User job story

When I have confirmed my email address on Wikipedia,
I want to no longer see the start/email module,
So that I can see and use the Suggested edits module and other content more prominently at the top of my homepage.

Proposed design
  1. There is a close "x" icon button added to the confirmed email state of the start module so that users can choose to remove the module (or module preview as is the case on mobile)
  2. Upon selecting the "x" button, the user will see a toast message (using the MessageWidget) that they can edit or remove their email at any time by going to their Preferences.
Confirmed email state (Desktop & Mobile)
image.png (384×1 px, 37 KB)
Message notification
image.png (130×956 px, 10 KB)

Notes on the design:

  • We want to give users the option to remove the module instead of it disappearing on its own
  • The dialog lets the user know how to change their email if they hid this in error.
  • The module will re-appear if the confirmed email address is removed.
Acceptance Criteria:

Given I'm a logged in user who has not added an email address to my account or I have not confirmed my email address,
When I visit the newcomer homepage,
Then I see the email module and it is NOT dismissible (there is no "x" to remove the module)


Given I'm a logged in user who has added an email to my account and confirmed the email address,
When I visit the newcomer homepage,
Then I see the email module and it is dismissible (there is an "x" to remove the module)

  • And once I dismiss the module, then I receive a toast message (using the MessageWidget):

Your email address can be changed or removed from Preferences.

  • And once I dismiss the module, it won't appear on my homepage on returning visits.

Event Timeline

RHo triaged this task as Low priority.Feb 18 2021, 7:19 PM
MMiller_WMF renamed this task from Newcomer homepage: Allow users to remove the start module from the homepage once their email is confirmed to Homepage: allow users to remove the start module from the homepage once their email is confirmed.Feb 22 2021, 5:10 AM
MMiller_WMF subscribed.
kostajh renamed this task from Homepage: allow users to remove the start module from the homepage once their email is confirmed to Homepage: allow users to remove the startemail module from the homepage once their email is confirmed.Aug 18 2021, 7:45 AM
kostajh updated the task description. (Show Details)

@KStoller-WMF Hmm my only concern there, if we're thinking about the lowest common denominator, is that some users might think that the "X" is to remove their email from the account. I think the solution works in principle, though.

I agree this is a possibility, but it seems like the toast message addresses this concern somewhat.

Would we also want to consider simply dismissing the module by default when an account has a confirmed email address?

I think the issue is, unless I'm misunderstanding, the user only gets the toast message if they've already clicked the X. So someone who thinks the X is to remove their email will never get the message saying that it isn't. I think removing by default is a good thing to consider. I'd think basically all users in 2023 have an expectation that any website they verify their email with still knows that email, without needing a prominent reminder.

I think the issue is, unless I'm misunderstanding, the user only gets the toast message if they've already clicked the X. So someone who thinks the X is to remove their email will never get the message saying that it isn't. I think removing by default is a good thing to consider. I'd think basically all users in 2023 have an expectation that any website they verify their email with still knows that email, without needing a prominent reminder.

The close is in the end of the module for that reason to avoid the error of people thinking it is for removing the email. I understand that for the small percentage of people who think it is to remove a confirmed email, having the toast message is actually helpful so they understand it is not removed but is located in preferences. Overall, the intention would be for a toast to appear on a page when any module is removed to give user feedback on their action. In case part of the concern is thinking this message replaces the email module forever, it doesn't, but merely shows up temporarily (~5--7secs) on the screen.

I had considered the option to have it automatically with no user action needed once confirmed, but it seemed to give less customisation flexibility in case the start email module is ever considered for other "quick start" content as it once use to have. If we don't think this is likely and are fine with potential for people to not realise how/where the email module disappeared after confirming it on email (a separate action to the homepage), then this ok.
One question is if in the latter solution whether this means that the module won't be removed after confirming the email until the user refreshes the homepage or else leaves and returns? If so, is this fine?

In T275155#9011449, @RHo wrote:
I had considered the option to have it automatically with no user action needed once confirmed, but it seemed to give less customisation flexibility in case the start email module is ever considered for other "quick start" content as it once use to have. If we don't think this is likely and are fine with potential for people to not realise how/where the email module disappeared after confirming it on email (a separate action to the homepage), then this ok.

Oh, interesting, I didn't realize that module used to have more content.
Since I don't see us working on adding any other "quick start" content in the immediate future, perhaps we should just treat it as the email confirmation module it really is today and have it automatically dismiss after the newcomer confirms their email.

In T275155#9011449, @RHo wrote:
One question is if in the latter solution whether this means that the module won't be removed after confirming the email until the user refreshes the homepage or else leaves and returns? If so, is this fine?

I think it's likely fine if the module remains until after the user refreshes the page or leaves and returns to the homepage. Perhaps that's not the perfectly responsive UX, but it still seems like an improvement over the existing UX, right?

In T275155#9011449, @RHo wrote:
I had considered the option to have it automatically with no user action needed once confirmed, but it seemed to give less customisation flexibility in case the start email module is ever considered for other "quick start" content as it once use to have. If we don't think this is likely and are fine with potential for people to not realise how/where the email module disappeared after confirming it on email (a separate action to the homepage), then this ok.

Oh, interesting, I didn't realize that module used to have more content.
Since I don't see us working on adding any other "quick start" content in the immediate future, perhaps we should just treat it as the email confirmation module it really is today and have it automatically dismiss after the newcomer confirms their email.

In T275155#9011449, @RHo wrote:
One question is if in the latter solution whether this means that the module won't be removed after confirming the email until the user refreshes the homepage or else leaves and returns? If so, is this fine?

I think it's likely fine if the module remains until after the user refreshes the page or leaves and returns to the homepage. Perhaps that's not the perfectly responsive UX, but it still seems like an improvement over the existing UX, right?

My proposal would still be one that gives the user control to remove the module especially as they are a newer user so may not be aware of how to change or remove the email when it disappears after taking an action elsewhere (confirming by following a link in their email). However, agree that removing automatically after confirmation is an improvement with current situation.

KStoller-WMF raised the priority of this task from Low to Medium.Jul 17 2023, 8:41 PM
KStoller-WMF updated the task description. (Show Details)

In T275155#9018759, @RHo wrote:
My proposal would still be one that gives the user control to remove the module especially as they are a newer user so may not be aware of how to change or remove the email when it disappears after taking an action elsewhere (confirming by following a link in their email). However, agree that removing automatically after confirmation is an improvement with current situation.

OK, I've added acceptance criteria that I believe represents the behavior you are suggesting. Feel free to review or revise. Thanks!

I think this task is unblocked now :)

Thanks, @Iniquity! There might be a few more related tasks that need to wrap up first: T354459: [Epic] Support conditional defaults for user properties to help address user_properties table bloat, but hopefully we can work on this soon.

Thanks, @Iniquity! There might be a few more related tasks that need to wrap up first: T354459: [Epic] Support conditional defaults for user properties to help address user_properties table bloat, but hopefully we can work on this soon.

Thank you! Considering that this task is about user safety, since we show everyone their email, I would be glad to see it resolved as soon as possible. It might be worth separating the tasks and separately highlighting the “encryption” of the email address if it would be faster.