Is this for mobile and/or desktop @Cntlsn

@JTannerWMF For both, thanks!

In T225318#5243473, @MMiller_WMF wrote:

@Catrope told me that the sitenotice option is actually feasible. @Catrope, could you fill us in on your recommendations for these users?

Not all types of site notices work in no-JS, because some of them are based on stuff like geo location. However, if all our links/redirects that lead from the account creation / welcome survey flow to wherever users end up next add a query string parameter (say, ?showhomepagetour=1), then we could see that query string parameter on the server side and output a site notice into the HTML. No-JS users will then see that site notice. For JS users, that site notice HTML will also be delivered, and we can either let it stand, or hide it with CSS and instead show a GuidedTour (or display both).

Looking at the list of flows at T222852#5215099, it looks like a query string approach would work for everything except the "abandon" flow, because that's the only one that doesn't involve a redirection or a click on a link that we control.

Alternatively, we could use a hidden user preference to indicate whether the banner/tour has been displayed already, and display the banner/tour only if that preference isn't set. That's also something we could detect both server-side and client-side.

Curious to hear thoughts on these implementation strategies from @SBisson and @kostajh too.

In T225318#5247164, @Cntlsn wrote:

[..] I tried disabling Js (Firefox 67) and couldn't see them on no-JS

• sitenotice banner shown on Js-enabled
  

• sitenotice banner NOT shown on no-Js
  

Just for the record: Site notices are shown to all logged-in users (with and without JS), and to unregistered users (only with JS). In the above example, it was not shown because it was not a logged-in page view. This distinction is made for the benefit of search engines (whether that is still useful is a separate question - T11209).

Thanks @Krinkle for the clarification, and thanks @Catrope for explaining how this could actually be done.

I would then go ahead designing banners to be placed in the sitenotice area, but I would have a couple more questions for @Catrope to make sure I understand correctly how this could work:

• the banners we show to no-Js users won't be auto-dismissible with a timer, and won't be dismissed by user interaction. I guess it should still be possible to use either the query string approach or the user preference to only show the banners to no-Js users once (only after account creation), but wanted to double-check that.
• in the scenario of redirecting to editing context, I assume it wouldn't be possible to show a banner above the editor. if that's the case, do you think it would be possible to make any changes to the page (editor) at all, or shall we better work in the chrome area?

In T225318#5256845, @Cntlsn wrote:

• the banners we show to no-Js users won't be auto-dismissible with a timer, and won't be dismissed by user interaction. I guess it should still be possible to use either the query string approach or the user preference to only show the banners to no-Js users once (only after account creation), but wanted to double-check that.

Yes, that's right.

• in the scenario of redirecting to editing context, I assume it wouldn't be possible to show a banner above the editor. if that's the case, do you think it would be possible to make any changes to the page (editor) at all, or shall we better work in the chrome area?

We can show a banner, but VE hides the sitenotice banner when it opens. Fighting that would be tricky and probably not worth it. We could still display a GuidedTour though.

• in the scenario of redirecting to editing context, I assume it wouldn't be possible to show a banner above the editor. if that's the case, do you think it would be possible to make any changes to the page (editor) at all, or shall we better work in the chrome area?

We can show a banner, but VE hides the sitenotice banner when it opens. Fighting that would be tricky and probably not worth it. We could still display a GuidedTour though.

@Catrope maybe you got confused by my question, I was referring to going back to editing context for no-Js users. they won't get VE, correct? would it be possible then to show a banner on top of wikitext editor?

Right, a no-JS user wouldn't get VE, good point :) . Yes, for the wikitext editor in no-JS mode, we could show a banner.

Thanks @Catrope for your input on this!

Taking into consideration the conversation above (and at T212280) and the approach taken in T222852, I have iterated on the proposed solution.
For noJs users that just created an account, I propose to display two different kinds of banners in the site notice area of the screen.

Banners specifications:

• All banners will feature
  • House / home illustration to make the banner visually attractive while reinforcing the main content == the homepage discovery
  • Account creation success header -- "Thanks for creating your account!"
  • An "X" icon in the top right corner of the banner to dismiss it
• Scenario A: After account creation, user chooses to go to Homepage
  • Text describing what the Homepage is about and how to get back to it -- "This is your homepage to help you getting started with editing, you can always click on [username] to return here."
    • [username] will be preceded by the user avatar icon (in-line), and should be progressive blue to mimic the exact same UI composition in the personal tools, and let user create the association between the banner and the link to the Homepage in personal tools.
    • [username] should never be hyphenated.
      
• Scenario B: After account creation, user chooses to go back to original context (being either reading an article or wikitext editor), or user abandons the survey
  • Text pointing to the Homepage link in the personal tools area, and inviting the user to discover the Homepage to get started editing "Click on [username] at the top of the page to discover your personal homepage and get started with editing."
    • [username] will be preceded by the user avatar icon (in-line), and should be progressive blue to mimic the exact same UI composition in the personal tools, and let user create the association between the banner and the link to the Homepage in personal tools
    • [username] should never be hyphenated
      

@MMiller_WMF moving it to your column in the Growth-Design board to double-check copy.
Also, before updating specs there are a couple of outstanding questions:

• Considering the inability of pointing directly to the Homepage link in the personal tools area, I think it's important to note that my design proposal relies heavily on the visual association between the banner content and the Homepage link. That said, I think it would be smart to address the issue of the username link color (T226113) before or contextual to the release of this same feature
• We have two different options to approach the banner's CTA:
  1. My preferred approach would be to not have a clickable CTA in the banner, causing the user to make the association between the content displayed in the banner and the link in the personal tools, and having to click the link to proceed to the Homepage.
  2. Potentially we could make the username mirrored in the banner a link, just as the one in the personal tools, and make it go to the Homepage. This approach would probably maximize conversion, but at the same time it would possibly miss the chance of training the user about how to reach the Homepage in the future. (It would also need to be instrumented)
• How "aggressive" do we want the discovery campaign to be? Shall we only show the banner once after account creation, or shall we show it until the action is taken or the user dismisses it?

Thanks @MMiller_WMF for your comments. Below are the iterated mockups we already discussed.

• Scenario A: After account creation, user chooses to go to Homepage
  
• Scenario B: After account creation, user chooses to go back to original context (being either reading an article or wikitext editor), or user abandons the survey
  

Specifications would be the same as T225318#5279796, with the exception of [username] not being highlighted, and being instead the same color as the standard text in order to avoid being misinterpreted as a link.

Could you please double-check copy?

If we are ok with this, and when copy is ready, I can update specifications and upload new mockups to zeplin/invision.

Per T224883 I am removing the mobile tag, @Cntlsn please confirm if that's correct. Thanks!

An "X" icon in the top right corner of the banner to dismiss it.

@MMiller_WMF @Cntlsn Is this important to have? As son as the user clicks away from the page, they should not see the banner again -- unless they visit Special:Homepage again and ?source=specialwelcomesurvey is in their browser URL.

I ask because it adds on extra time to implement this feature with pure HTML and CSS.

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

As @Catrope noted in T225318#5255623, handling the case where the user abandons of the survey is more difficult but not impossible. For example we could look at the HTTP_REFERER header to see if the user arrived from Special:WelcomeSurvey.

Similar to the concern about the "Dismiss" button, it's do-able but if we don't think it's critical, then we might consider leaving that for another day.

Do we have metrics on how many no-JS users are in our experiment groups at the moment? If it's relatively few, then my recommendation would be to not handle more difficult cases that require larger engineering efforts.

Thanks @kostajh for the comments and for removing the mobile tag!

I think removing the possibility to dismiss the banner won't be a too big deal in terms of experience, so I'll be fine with not working on that.

About the scenario where user abandons the survey, those users won't get any hint about the Homepage, and of course that would be a missed opportunity. But I also agree that it's probably a few amount of them. I don't see a big issue under those circumstances, but I think it's up to @MMiller_WMF to decide on that with a better understanding of the numbers.

Change 526179 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] (wip) Homepage discovery for desktop no-JS users

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

@kostajh @Cntlsn -- thanks for discussing this. I'll change the specifications in the description to forego the "X" to close the banner.

For users who abandon the survey, I think we should keep that requirement. The reason is because although it's not critical, and it is likely a low number of users, this is actually a good time for us to a non-critical task like that, since we are still assembling specifications for "newcomer tasks". I also think we'll have less cognitive load in the future if we do that additional work to make sure all desktop users find out about the homepage, as opposed to it being like "all desktop users find out about the homepage except no-JS users who abandon the survey".

But please let us know if this becomes overly burdensome, and we can re-evaluate. Like, I think it's worth doing if it's in the "couple more hours" range.

Change 526179 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Homepage discovery for desktop no-JS users

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

@kostajh - Welcome survey does not work for me when javascripts is disabled in browser. I used ?showwelcomesurvey=1&group=exp2_target_popup to trigger the survey and also test with a user who has growthexperiments-tour-homepage-discovery property set to 0.

@Etonkovidova -- I tried to test this by creating a new account with Javascript, but I was not even able to create the account. I got an error message on the account creation page saying:

Does this happen to you?

In T225318#5489413, @MMiller_WMF wrote:

@Etonkovidova -- I tried to test this by creating a new account with Javascript, but I was not even able to create the account. I got an error message on the account creation page saying:

Does this happen to you?

Yes, it's been happening for couple of days in betalabs. I checked with production - account creation works as expected. I reported the issue in T232796.

Moving for Design Review - the username and user icon looks a bit off.
Checked in testwiki wmf.23
Scenario A: After account creation, user chooses to go to Homepage

Scenario B: After account creation, user chooses to go back to original context (being either reading an article or wikitext editor), or user abandons the survey.

Note: The Echo Welcome notification is unchanged.

In T225318#5504909, @Etonkovidova wrote:

Moving for Design Review - the username and user icon looks a bit off.
Checked in testwiki wmf.23
Scenario A: After account creation, user chooses to go to Homepage

Scenario B: After account creation, user chooses to go back to original context (being either reading an article or wikitext editor), or user abandons the survey.

Note: The Echo Welcome notification is unchanged.

thanks @Etonkovidova - the icon is definitely off.
Expected in both scenarios is that the icon is 20x20px (the standard 100% size in OOUI), and color is Base20 (#54595d)
(In the actual screenshots posted above, it looks like the icon is 1.5x the expected size).

@RHo does this look better?

And color is Base20 (#54595d)

The icon is loaded as an SVG as a background-image (see also T198770). I guess we could have our own SVG/PNG that's in the color you'd like?

In T225318#5525968, @kostajh wrote:

@RHo does this look better?

And color is Base20 (#54595d)

The icon is loaded as an SVG as a background-image (see also T198770). I guess we could have our own SVG/PNG that's in the color you'd like?

Hi @kostajh - it does look better but think it still needs to be shifted 2px to the right and 2px higher to align better with the username.

And rather than make our own, can we use the same SVG as the avatar icon in the personal tools section which is in the same Base20 color?

This comment is also relevant for @Tgr on a similar task T224883#5525883

And rather than make our own, can we use the same SVG as the avatar icon in the personal tools section which is in the same Base20 color?

Ah, right. That's user-avatar.svg and user-avatar.png from the Vector skin, which will be fine since this task is just about desktop in particular. I had added the icon via OOUI.

A slightly hacky approach (hacky in a different way than cross-referencing an asset from an unrelated skin, that is) is to apply opacity: 0.4777 (0x77 / 0xff) which will result in a color very close to #72777d.

In T225318#5526984, @Tgr wrote:

A slightly hacky approach (hacky in a different way than cross-referencing an asset from an unrelated skin, that is) is to apply opacity: 0.4777 (0x77 / 0xff) which will result in a color very close to #72777d.

Yes exactly this. This is how we have made OOUI icons various shades of grey in a lot of places.

In T225318#5535224, @Catrope wrote:

In T225318#5526984, @Tgr wrote:

A slightly hacky approach (hacky in a different way than cross-referencing an asset from an unrelated skin, that is) is to apply opacity: 0.4777 (0x77 / 0xff) which will result in a color very close to #72777d.

Yes exactly this. This is how we have made OOUI icons various shades of grey in a lot of places.

• Fair enough, OK with this for the grey colour. However, will discuss with @Catrope (and @Volker_E ?) if there is some way we should be able to change icons to other colours in the color palette easily without requiring this hacky workaround in future.

In T225318#5526984, @Tgr wrote:

opacity: 0.4777 (0x77 / 0xff)

0.5222, actually, since 1 would result in the icon staying black and 0 in it becoming full white, so the resulting color will be rgb(1-opacity, 1-opacity, 1-opacity).

Change 540371 had a related patch set uploaded (by Kosta Harlan; owner: Kosta Harlan):
[mediawiki/extensions/GrowthExperiments@master] Homepage discovery: adjust avator icon color and size

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

Change 540371 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Homepage discovery: adjust avator icon color and size

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

For Design review - the size is 20x20 and the opacity (and the contrast) seem to be right:

Before	After

The properties:

@RHo For completion, that's what we do currently for all greyish variants of OOUI icons due to excellent cross-browser support of opacity and simplicity.
Compare WikimediaUI Base opacity vars. Gergő was correct.
In future we might rely on CSS filters, but currently they bring too many unresolved technical issues.

In T225318#5542468, @Etonkovidova wrote:

For Design review - the size is 20x20 and the opacity (and the contrast) seem to be right:

Before	After

The properties:

thanks @Etonkovidova the colour looks OK now.
however @kostajh - this is super minor but the icon position is still a little off - should be sorted by adding 4px between the icon and $Username, and for the icon to be moved up by 2px. Thanks!

Thanks for spending time thinking about this, @Tgr, @kostajh, @Etonkovidova, @RHo. Given that we've spend a lot of time on this task, I think we need to refrain from making any other adjustments and deploy it the way it is. No-JS users are in the vast minority, and our main directive with our no-JS work is to make sure those users are not blocked on using functionality. I think the work in the current state satisfies that requirement, and so we should not spend additional time on this task.

@Etonkovidova -- if this is scheduled to ride the train, then I think you can resolve this task.

It might be possible to have a dismissible sitenotice, compatible with No-JS, and clean search engine results. -> T11209#7686457

@adrelanos this task is about a notice shown to logged-in users, so there is no overlap with the search engine results discussion from what I can see.