In T341195#9010265, @Tamzin wrote:

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

In T275155#9010789, @Tamzin wrote:

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#9016376, @KStoller-WMF wrote:

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.

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!

Blocking until T321527 is complete.

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.

In T275155#9471138, @KStoller-WMF wrote:

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.

Hi! Is there any progress? I see this module is no longer appear on the new screenshots.

Thanks for surfacing this task again.

Is there any progress? I see this module is no longer appear on the new screenshots.

Unfortunately no. It looks like those design mockups are missing the startemail module. I'll ask Growth's designer to make an update to that Commons file.

Now that this task is unblocked (T354459 is resolved), I'll discuss prioritization with the Growth team.

In T275155#10252295, @KStoller-WMF wrote:

Thanks for surfacing this task again.

Is there any progress? I see this module is no longer appear on the new screenshots.

Unfortunately no. It looks like those design mockups are missing the startemail module. I'll ask Growth's designer to make an update to that Commons file.

Now that this task is unblocked (T354459 is resolved), I'll discuss prioritization with the Growth team.

Thank you for your prompt response! :)

If someone is currently worried about their safety, then this block can be hidden using CSS.

div[data-module-name="startemail"] {
  display: none;
}

@KStoller-WMF i've updated the task description based on our conversation, hence moving the task into the backlog.

This appears to be a straightforward change, so I’m moving it to Up Next.

As I understand it, we’re adding logic to hide the startemail module once an email address has been both added and confirmed.

This behavior should apply consistently across both desktop and mobile.

@Sgs – could you please review and let us know if there are any technical questions before this task becomes estimatable / actionable?

In T275155#10755305, @KStoller-WMF wrote:

@Sgs – could you please review and let us know if there are any technical questions before this task becomes estimatable / actionable?

It's indeed actionable, I wasn't sure about the existence of user_email_authenticated field but it's definitely what we need to hide the module.

re IP address: I tried and failed to find the original reason to have the IP address written down in the email body, followed comments from T215665, specifically T215665#4967518, which seems to indicate that the IP address was added from the very beginning of the feature creation. I find it quite disrupting for a non-technical reader. Even for people that know what IP addresses are, validating the IP is "my own IP" could be tricky. I believe the original argument could be related to safety, in the sense that as a user I want to be sure I originated the confirmation action, for instance GitLab adds an IP address on sign-in attempts (along with the source domain and timestamp). For non-technical users it might be more useful to add the timestamp on which the confirmation request was originated rather than the IP. Or maybe both but make IP less prominent.

In T275155#10771879, @Sgs wrote:

In T275155#10755305, @KStoller-WMF wrote:

@Sgs – could you please review and let us know if there are any technical questions before this task becomes estimatable / actionable?

It's indeed actionable, I wasn't sure about the existence of user_email_authenticated field but it's definitely what we need to hide the module.

re IP address: I tried and failed to find the original reason to have the IP address written down in the email body, followed comments from T215665, specifically T215665#4967518, which seems to indicate that the IP address was added from the very beginning of the feature creation. I find it quite disrupting for a non-technical reader. Even for people that know what IP addresses are, validating the IP is "my own IP" could be tricky. I believe the original argument could be related to safety, in the sense that as a user I want to be sure I originated the confirmation action, for instance GitLab adds an IP address on sign-in attempts (along with the source domain and timestamp). For non-technical users it might be more useful to add the timestamp on which the confirmation request was originated rather than the IP. Or maybe both but make IP less prominent.

In case it's useful, I like Amazon's sign-in attempt email:

 When: 	May 10, 2024 01:47 PM Eastern Daylight Time 
Device: 	Google Chrome macOS (Desktop) 
Near: 	Some city, Some country

This uses the IP implicitly to get geolocation, and the user agent to show the device.

I am not sure if both are needed for adding an email to an account, but it's probably more user-friendly than showing the IP address directly.

Change #1139900 had a related patch set uploaded (by Cyndywikime; author: Cyndywikime):

[mediawiki/extensions/GrowthExperiments@master] Hide startemail module when email is confirmed

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

In T275155#10771982, @kostajh wrote:

In T275155#10771879, @Sgs wrote:

In T275155#10755305, @KStoller-WMF wrote:

@Sgs – could you please review and let us know if there are any technical questions before this task becomes estimatable / actionable?

It's indeed actionable, I wasn't sure about the existence of user_email_authenticated field but it's definitely what we need to hide the module.

re IP address: I tried and failed to find the original reason to have the IP address written down in the email body, followed comments from T215665, specifically T215665#4967518, which seems to indicate that the IP address was added from the very beginning of the feature creation. I find it quite disrupting for a non-technical reader. Even for people that know what IP addresses are, validating the IP is "my own IP" could be tricky. I believe the original argument could be related to safety, in the sense that as a user I want to be sure I originated the confirmation action, for instance GitLab adds an IP address on sign-in attempts (along with the source domain and timestamp). For non-technical users it might be more useful to add the timestamp on which the confirmation request was originated rather than the IP. Or maybe both but make IP less prominent.

In case it's useful, I like Amazon's sign-in attempt email:

 When: 	May 10, 2024 01:47 PM Eastern Daylight Time 
Device: 	Google Chrome macOS (Desktop) 
Near: 	Some city, Some country

This uses the IP implicitly to get geolocation, and the user agent to show the device.

I am not sure if both are needed for adding an email to an account, but it's probably more user-friendly than showing the IP address directly.

+1, notion does something similar for sign-in attempts. agreed that including and relying only on the IP is not sufficient for folks without technical background/interest

Change #1139900 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Hide startemail module when email is confirmed

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

Should we create a follow-up task for the verification email content, or recycle T215665: [Design] Emailability: Improve verification email? cc @KStoller-WMF

Yes, let's use that task for the follow up email improvements!
I've updated the task, I want to discuss and have design take a look before we take action.

Tested on en.wikipedia.beta

Acceptance Criteria is met:
✅ If user has not confirmed their email the module is visible
✅ If user has confirmed their email the module is hidden
✅ If user changes or removes their email the module is visible

Specifics of what I tested:
✅ email module displays when no email is added to an account: with Add email CTA
✅ When an email is added, but not yet confirmed, the email module displays with a (confirm) CTA
✅ Once email address is confirmed the email module isn't displayed on the homepage
✅ If I remove my email address (from Preferences) then the email module displays on the homepage again as expected

Thankyou @KStoller-WMF , for thoroughly testing this :)