Below are the updated mockups for Mobile landscape view and Tablet.
Mockups are up-to-date in Zeplin and InVision too.

Mobile landscape
(This mockup is optimized for smaller screens iPhone5/SE -- it will scale up by just adding white space around the main text on bigger screens)

Tablet portrait

In T224883#5384951, @Cntlsn wrote:

I have reason to believe that there would be no overlapping between the two features, since the banner will only be displayed right after account creation, which is before any users can manually enable AMC.

However, I do foresee a potentially confusing scenario:

• user creates a new account
• user receives the banner
• user learns to go to the Homepage by tapping on the username in the side menu
• user activates AMC (let's say inadvertently since it's a feature for advanced users, not for newcomers)
• user can't find the link in the side menu and can't access the Homepage anymore

My proposal here would be to add a third type of banner, only triggered when enabling AMC if also Homepage is enabled, showing the user the new path to the Homepage.

@MMiller_WMF @RHo @kostajh @Catrope How does that sound? Am I overthinking it? Is the new user menu icon already self-explanatory?

Given that it is an extreme edge case which involves a person being familiar enough to enable AMC in preferences to get this new user menu icon, I vote for *not* showing another banner. Besides the low chance of this occurring, I favor more prudence with banner use to avoid more conflicts (such as T189569) occurring.

Thanks @RHo!

I have added mobile landscape and tablet specifications to the task description.

@MMiller_WMF feel free to move to ready for development if all looking good and you agree with not proceeding with a third banner.

This is ready to be worked on, and is a high priority because it will have a substantial impact on the homepage discovery rate (and therefore the newcomer task discovery rate) for mobile users. I'm putting it in Ready for Development so we can prioritize against newcomer tasks work.

Change 539176 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] [WIP] Homepage: add banners for mobile discovery

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

The patch deviates from the design in the icon color (which OOUI doesn't really support changing, and it didn't seem worth the complexity to use some manual icon code instead), and looks a bit different on wider screens (where Minerva doesn't quite look like the design mockup):

narrow	wide	wider	widest

Hm, needs a little more work for the "can only be seen once" part.

Also per comments in T225318#5526093.

In T224883#5525883, @Tgr wrote:

The patch deviates from the design in the icon color

Fixed via the opacity hack.

I made the mobile and no-JS versions use the same logic: the banner will only appear to the user once. For no-JS this was not in the specification but seemed like the logical thing to do. It's trivial to change if it's not wanted.

Also made the mobile version share settings with the desktop version (ie. if you see the banner on mobile it will use the same flag to mark as seen, so you won't get the tour on desktop anymore). I don't think it matters in practice as they are only shown immediately after registration so there wasn't any non-fringe scenario in which the user could trigger discovery in both modes, anyway.

A note from standup today: @Tgr will post a screenshot of what the word-wrap/icon issue looks like so we can decide whether it's important.

In T224883#5527644, @Tgr wrote:

I made the mobile and no-JS versions use the same logic: the banner will only appear to the user once. For no-JS this was not in the specification but seemed like the logical thing to do.

Also made the mobile version share settings with the desktop version (ie. if you see the banner on mobile it will use the same flag to mark as seen, so you won't get the tour on desktop anymore). I don't think it matters in practice as they are only shown immediately after registration so there wasn't any non-fringe scenario in which the user could trigger discovery in both modes, anyway.

Removed this after Kosta pointed out this would break the use case where after registration the user returns into an edit form (and so the banner is hidden) and only after a save + page reload ends up in a place where the banner could be shown. So now the banner is shown whenever the query parameter for it is present in the URL, just like in the no-JS case. This means the user can see the banner multiple times if they reload the page or back-arrow-navigate.

In T224883#5538273, @MMiller_WMF wrote:

A note from standup today: @Tgr will post a screenshot of what the word-wrap/icon issue looks like so we can decide whether it's important.

Here's a screenshot courtesy of Kosta:

There's a word joiner character between the icon and the name which in theory should prevent word break. This works in Chrome but not in Firefox. (Firefox does honor word joiners in some situations, I couldn't figure out why exactly it does not here - I tried to make the icon span non-empty, that didn't help.) The workaround would be to split the username into words, wrap the icon + first word into a span and apply white-space: nowrap to it, but I'm unsure if that would create problems with scripts which have different line breaking conventions.

In T224883#5538864, @Tgr wrote:

In T224883#5538273, @MMiller_WMF wrote:

A note from standup today: @Tgr will post a screenshot of what the word-wrap/icon issue looks like so we can decide whether it's important.

Here's a screenshot courtesy of Kosta:

There's a word joiner character between the icon and the name which in theory should prevent word break. This works in Chrome but not in Firefox. (Firefox does honor word joiners in some situations, I couldn't figure out why exactly it does not here - I tried to make the icon span non-empty, that didn't help.) The workaround would be to split the username into words, wrap the icon + first word into a span and apply white-space: nowrap to it, but I'm unsure if that would create problems with scripts which have different line breaking conventions.

Initially, looking at the screenshot it's not that bad, and also given that adding a non-breaking space will work in at least some browsers I would say this seems acceptable.

However, I wonder if it is possible to have the icon in the background-image part of the span.

<style>
.icon-avatar {
    background-position: center left;
    background-repeat: no-repeat;
    background-image: url(https://en.wikipedia.org/w/skins/Vector/images/user-avatar.png?59494);
    padding-left: 24px;
}
</style>

<p>Open the side menu and tap <span class="icon-avatar">Usernameofsomebody</span> to visit your homepage.
</p>

Apologies if this was already tried as I missed the convo in standup, or is wrong for another reason as IANAFED.

@Tgr -- I think if you don't have a very easy fix handy, we should move on without this fixed. It's in a minority browser, and not a high priority.

In T224883#5539034, @RHo wrote:

However, I wonder if it is possible to have the icon in the background-image part of the span.

That would probably work; I'm using the OOUI helper which creates HTML like tap <span class="icon-avatar"></span>Usernameofsomebody to visit. That's less flexible but more maintainable (it won't break if OOUI changes icon locations or CSS or some other detail).

Change 539176 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Homepage: add banners for mobile discovery

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

The screenshots for Design review (I checked landscape orientation on mobile phones, but not on the tablet; will do it).

• also, please not @Tgr comment - https://phabricator.wikimedia.org/T224883#5525883
• the message layout/functionality looks fine to me (the disadvantage of username being bold was discussed above and it seems there is no danger of having AMC as default)

Thanks @Etonkovidova, LGTM

@Etonkovidova -- I am trying to test this on beta, but things are not working out for me. First I tried to test it from my phone, but when I went to the mobile site to create an account, I opened up the left navigation and got a blank menu:

Then I tried to do it from my desktop, and upon creating an account I got this:

Do you see these problems?

Also, once I create an account, will it automatically have the homepage on and get the discovery feature?

The second one is T228088: BetaCluster: ExternalStoreException - Unable to store text to external storage (that one is about editing pages, but the underlying issue seems to be the same, some kind of ExternalStore misconfiguration).

@Etonkovidova -- could you please comment on my ability to test this? Please see my previous comments above.

In T224883#5545807, @MMiller_WMF wrote:

@Etonkovidova -- I am trying to test this on beta, but things are not working out for me. First I tried to test it from my phone, but when I went to the mobile site to create an account, I opened up the left navigation and got a blank menu:

Account creation works fine now (it was a temporary problem, as @Tgr mentioned).

Also, once I create an account, will it automatically have the homepage on and get the discovery feature?

For Welcome survey you'll need to use Special:WelcomeSurvey?_group=exp2_target_specialpage. Homepage is not enabled for all users, you may need to enable it from the Preferences.

@Etonkovidova -- the train email by @Catrope last week said this feature rode last week's train, so I expected to see it in production this week. I just created an account in Czech Wikipedia, and that account had the homepage turned on by default, but it did not get any banners. Could you please check this out in production?

In T224883#5577960, @MMiller_WMF wrote:

@Etonkovidova -- the train email by @Catrope last week said this feature rode last week's train, so I expected to see it in production this week. I just created an account in Czech Wikipedia, and that account had the homepage turned on by default, but it did not get any banners. Could you please check this out in production?

From the task description- "[...] the most important time to help newcomers discover their homepage is the moment after account creation, which means after the welcome survey."

There is a case when a user navigates away from Welcome survey (not clicking on "Submit" or "Skip"). Then, no information about homepage would be presented to a user.

I created two accounts on cswiki, and after I got Welcome survey, I submitted the survey for one account and I skipped it for another account (by clicking on "Skip the survey" .
(1) For the first account - after submitting Welcome survey, I clicked on go to your Homepage and got Homepage with a banner:

(2) The second account - I click to Skip Welcome survey and went to a random article - the banner was displayed.

Per discussion with @MMiller_WMF, the following case seems not be covered, e.g. when a user abandons the Welcome survey by navigation away.

Scenario B: After account creation, user chooses to go back to their original context, or user abandons the survey.

Note for future testing: Make sure that the following case is also covered

• a user creates an account from editing context and from reading context

Change 565406 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Make sure to show mobile homepage discovery notice at least once

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

The current behavior is:

• If you click on some link that's part of the survey, like the "skip" button, since we control the URL, we put a tag in it, and on pages with that tag in the URL, we show the notice.
• If you use normal browser navigation (that is, click on a link in the hamburger menu, or in notifications or search results) then Special:WelcomeSurvey will be in the referrer, and again we detect that and display the notice.

The patch adds a "seen" flag that gets set when the notice is displayed on mobile; the notice gets displayed on any mobile pageview if the flag is false. The survey gets displayed in the cases where it was displayed previously, regardless of the flag (that's important because sometimes when returning to where the user started the registration process from, the content of the first pageview can be hidden by an overlay).

Change 565406 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Make sure to show mobile homepage discovery notice at least once

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

Needs RTL versions of the arrows.

I think the blue arrow is pointing the wrong direction. This screenshot is from ar beta

Change 566403 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Homepage discovery: fix RTL behavior

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

Change 566403 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Homepage discovery: fix RTL behavior

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

When Advanced mode is enabled on mobile, the arrow will incorrectly point to the menu that does not have a username link:

• the hamburger menu does not have the username link in Advanced mode

• the user name link is on a different side

With AMC enabled, the user menu is just before the close icon. @RHo any recommendations? Should we move the close icon to the left-hand site? The arrow does not have to be clickable so in theory we could just overlay the X icon on it, but it looks terrible.

In T224883#5825206, @Tgr wrote:

With AMC enabled, the user menu is just before the close icon. @RHo any recommendations? Should we move the close icon to the left-hand site? The arrow does not have to be clickable so in theory we could just overlay the X icon on it, but it looks terrible.

Hi @Tgr, agree it would look terrible and also for AMC we would need to change the whole message and icon show in the text as well (since the user is not opening the side menu, and the username would not be shown after the slightly different avatar icon. I would just just not have the arrow at all in the AMC version but instead have the message be amended to something like this:
Get started
Open your user menu by tap your user icon $avatar-icon, and then select your username to go to your homepage.

@MMiller_WMF do we know what % of users have AMC turned on and whether it is worth the effort to create a separate discovery experience? Esp as perhaps the venn diagram overlap of those who turn on AMC who are newbies that can't find their homepage might be somewhat small?

Changing the copy + removing the arrow is minimal effort if we are OK with that.

Thanks for noticing this, @Etonkovidova. On the one hand, AMC is pretty much only used by advanced users -- but on the other hand, I think it may become the default experience one day, and we should be able to handle that. I think we should do @RHo's idea about having a different message for AMC, which @Tgr said was minimal effort. I am amending the task description to say that.

Change 570188 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Add missing UserGetDefaultOptions hook

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

Change 570188 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Add missing UserGetDefaultOptions hook

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