Moving this to @Cntlsn's column for him to think about.

@MMiller_WMF

Here are two design proposals based on considerations highlighted in the task description.

1. Confirmation link in confirmation email will redirect user to the homepage. A toast will appear front and center, notifiying the user about email confirmation success "Your email address was confirmed!"

• Alignment: center aligned at the top of the page and below the personal tools
• Behavior: the toast would appear with a transition on it's opacity (0 to 1), and a slight movement from center top to its position. It would disappear the other way around, opacity transition (1 to 0), and a slight movement from its position to center top.

2. Email confirmation success page would simply show a clearer call-to-action to go to the homepage: a progressive button with copy "Go to Homepage"

I have a couple questions for @Catrope (or other engineers) about option #1 (redirect with toast)

• Given that users have landed on the email confirmation page for years, would immediately redirecting them to their homepage instead cause any problems? Do you know of any reason they actually need to land on and see the email confirmation page?
• What problems do you foresee with the toast? Will no-JS users not see it? What else can go wrong?

@Cntlsn -- how would you want to option #1 on mobile?

@Cntlsn you can experiment with the toast with running this in your console:

mw.notify( 'Your email has been confirmed', { title: 'Success!', autoHide: false, type: 'warn' } );

For the configuration options you can look at resources/src/mediawiki.notification/notification.js

Given that users have landed on the email confirmation page for years, would immediately redirecting them to their homepage instead cause any problems? Do you know of any reason they actually need to land on and see the email confirmation page?

I think the idea is just to tell the user it succeeded. They need to land on the page for the email to be properly verified but we can redirect them before they've seen the page load.

What problems do you foresee with the toast? Will no-JS users not see it? What else can go wrong?

Correct, no-JS users will not see it. One idea would be to have a "your email is verified" module that appears above the start module, and only show if the user has been redirected from Special:ConfirmEmail. That would provide more visibility and work for no-JS users.

I like Kosta's idea of showing a "your email is verified" message based on whether the user was redirected from Special:ConfirmEmail to the home page.

Overall I think redirecting from Special:ConfirmEmail to Special:Homepage (for users in the control group) is the best option. We can redirect to something like Special:Homepage?fromconfirmemail=1 so that we can then display the page slightly differently (e.g. adding the thing Kosta proposed, or the toast Alessandro proposed).

Thanks @kostajh and @Catrope for your feedback on this!

I also agree that redirecting the users to the Homepage would be the best option for the user experience.
Just want to make sure I understand correctly how this would work: after clicking on the link in the email, the Special:ConfirmEmail page will load and after some time it will redirect to Special:Homepage?
Or actually the redirect to Special:Homepage would be so quick that the user won't be able to see the Special:ConfirmEmail page?
The reason I'm asking is that if we're in the first scenario, then I think it would be good to offer some kind of feedback of what's happening to the user, like a message with indication that the user is being redirected and a countdown, or something similar.

Talking about the toast vs boxed message, I'd love the design treatment to also support no-JS. But, I was having a look T127405 and I'm afraid I'm not sure what's exactly the option that OOUI would like to see supported in the future.
I'm looping @Volker_E for guidance on this: considering this mockup, what do you think would be the best way to show the message in the toast?
Thx!

@Cntlsn The message should be either a success message (preferred) or a notice message. M241 shows the current iteration of the user system messages (block and inline).
So in contrast to the mockup I see following points to change:

• Change from warning to success colored message
• Add 'check' icon. It's then probably a good time to think about and revisit the icon accompanying “Start here” module
• Messages unlike other interactive elements don't receive border-radius: 2px – should be set to 0
• Save/publish success message in VE has a close icon as well
• Box-shadow should be added to overlay messages

Thanks @Volker_E for all your notes!

I'm not sure I understand if the kind of boxed messages in M241 can be used as toast messages?
And in case that's possible, do all toast messages have to appear from the right of the screen? Because in that scenario I think the message won't be very visible:

In case those kind of messages are not supposed to be used as toasts, is this the kind of treatment the message would get?

Thanks again, and sorry for all the questions, trying to make some clarity on this :)

Top/center would be aligned with VisualEditor save message, that seems fine for now.

I think the toast approach is good. Let's also include a design for no-JS users.

@kostajh @SBisson @Catrope -- do you recommend that we use the exact same message that is currently used on Special:ConfirmEmail?

Will this save us translation needs?

@Cntlsn -- please go ahead and change the description of this task to include the specifications and mockups.

In T222848#5241178, @Volker_E wrote:

Top/center would be aligned with VisualEditor save message, that seems fine for now.

That's how is the message whatever editor you successfully used. And the one for successful mentions IIRC.

do you recommend that we use the exact same message that is currently used on Special:ConfirmEmail?

That makes sense to me.

Will this save us translation needs?

Yes, I don't think we need to add a new translation string.

In T222848#5237747, @Cntlsn wrote:

Thanks @kostajh and @Catrope for your feedback on this!

I also agree that redirecting the users to the Homepage would be the best option for the user experience.
Just want to make sure I understand correctly how this would work: after clicking on the link in the email, the Special:ConfirmEmail page will load and after some time it will redirect to Special:Homepage?
Or actually the redirect to Special:Homepage would be so quick that the user won't be able to see the Special:ConfirmEmail page?
The reason I'm asking is that if we're in the first scenario, then I think it would be good to offer some kind of feedback of what's happening to the user, like a message with indication that the user is being redirected and a countdown, or something similar.

What I'm proposing is the second scenario: when you go to Special:ConfirmEmail, it would immediately (without displaying a page) redirect to Special:Homepage?fromconfirmemail=1, and Special:Homepage would notice the ?fromconfirmemail=1 parameter and display a message thanking the user for confirming their email.

Thanks @Catrope @kostajh @MMiller_WMF for your input.

If you confirm the following mockups are feasible, I will update the task description with detailed specifications.

Desktop Js

Desktop no-Js

Mobile Js

Mobile no-Js

Looping @SBisson in since we just discussed in chat that making a message dismissable for no-Js users would potentially be too much work for supporting a small percentage of no-Js browsers.

In the two no-Js scenarios above I would only consider displaying the message if browsing to another page and then back to the homepage would remove the message.
Would that be the case?

I think the mockups are feasible but in the no-js cases should we omit the dismiss button?

@Cntlsn -- please do update the task description and put this in ready for development. You can go ahead and specify the no-JS version as not having a dismiss button, and for the banner to go away when users refresh or revisit the homepage.

In T222848#5252939, @Cntlsn wrote:

In the two no-Js scenarios above I would only consider displaying the message if browsing to another page and then back to the homepage would remove the message.
Would that be the case?

Yes, except that if you go back using the browser back button, it might not be removed. The browser back button behaves strangely and in ways that we have little control over. If the user navigates to the homepage in any other way, the message would not appear a second time.

@Catrope Thanks for the details, that's what I expected.

@Volker_E Thanks for updating the specs.

Zeplin mockups are up-to -date

Change 520512 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] (wip) Reroute ConfirmEmailComplete hook to Special:Homepage

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

Change 520512 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Reroute ConfirmEmailComplete hook to Special:Homepage

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

@Cntlsn I'm not sure it's possible to get the checkmark into the notification for desktop JS version, at least not the way the notifications library is structured now. I would propose we proceed without the checkmark and then possibly come back to it as a follow-up later.

@kostajh I'm ok with proceeding without the checkmark for now!

I'm also looping in @Volker_E for possible further clarification on this.

Change 521535 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Fix accidentally working LESS for ConfirmEmail

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

Change 521535 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Fix accidentally working LESS for ConfirmEmail

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

Unable to check for a real confirmation (filed T227714). Meanwhile, here are screenshots done with `Special:Homepage&source=specialconfirmemail. @Cntlsn, please take a look for possible adjustments and move back to QA column for verification on confirmation email.

• no js ( 'x' button is missing)

The success icon should be Green50 (green), not Accent50 (blue).
In the message style guide design we've also been defining the text to run alongside the icon – the text shouldn't wrap below the icon like in the last mobile screenshot.

Thanks @Volker_E for your comments.
@kostajh raised a series of concerns about styling messages as per specifications on M241.
I agreed on moving forward anyway and then fixing later, but I will collect the observations below, so it would be nice if you could give a look and give your input:

• issue about getting the checkmark into the notification, mw.notify not being particularly flexible around this
  
• for no JS, not possible we get to choose the color of the checkmark. It's going to be blue or black
  

About reviewing the state of the design:

• @Etonkovidova The dismiss 'X' button will be missing as per M241 there are no dismiss buttons in messages, they just auto-dismiss or stay on screen I guess. In our case we discussed the behavior previously T222848#5266568
• Mobile no-Js version:
  • the message should feature margin on top and on the sides margin: 21px 16px 0;
  • (quoting @Volker_E) the text shouldn't wrap below the icon.

Temporarily keeping this in the Design review column until the issues above haven't been addressed.

@Cntlsn Checkmark icon should actually be either Base0 or Green50 (with latter we tolerate a color contrast issue on this specific icon as the message should be self-explaining and the boundaries are sufficient.

Change 523795 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Special:ConfirmEmail message: Make checkmark black

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

Change 523795 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Special:ConfirmEmail message: Make checkmark black

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

Looks good for now, so moving to "Needs PM review".
Might be revisited later, to match mockups.

It's important that we can test this fully in beta, so I'm moving this back to QA while we wait for the blocker (T227714) to be resolved by Release-Engineering-Team. (cc @JTannerWMF)

Change 524069 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Special:ConfirmEmail message: Make checkmark green

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

Change 524069 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Special:ConfirmEmail message: Make checkmark green

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

Still blocked by T227714 - not able to confirm email. @MMiller_WMF, I'll talk to @Catrope if there is a way to workaround the issue.

@Cntlsn - moving for Design Review. Please move it back to QA, so I'll continue testing the functionality.
The most recent screenshots for corrected checkmark:

There is a small misalignment for checkmark, but it seems the same as for other checkmarks on Homepage. Event when a label has descenders (the last screenshot) it's a little bit off:

Thanks @Etonkovidova, checkmarks look good.
I'm aware of icons misalignment, but I think it's ok for now (maybe creating a separate task for it).

Checked in testwiki (wmf.15):

Desktop
Desktop no-Js
Mobile
Mobile no-Js

Instrumentation was checked in betalabs eventlogging - event_referer_route=specialconfirmemail records users clicking on confirmation link and landing on Homepage.

All those confirmation email messages, with a clear design, should be deployed by default.

Looks good for now, moving to "Needs PM Review".
I'm taking notes of the UI bugs and will make a separate task for that.