Page MenuHomePhabricator

Homepage: homepage discovery for no-JS users (desktop)
Closed, ResolvedPublic

Description

In T222852, we designed GuidedTours to help users discover their homepage. GuidedTours don't work for users that don't use Javascript, so this task is about how to help no-Javascript users discover their homepage.

Below are @Cntlsn's comments on this.

About the treatment for no-Js users, I was planning to show them banners in the sitenotice area (and a modal for when they go back to editing context), but I did some research and apparently none of those are supported in no-Js wiki.
So my idea would be to rely on echo notifications in this scenario. Whatever the context of origin and the destination, I would suggest to slightly change the current "welcome" echo notification to say:

  • Header: "Welcome to Wikipedia, [username]! We're glad you're here."
  • Body: "Looking for a way to get started? Click on your username to visit your homepage."

Here is a mockup of how it would look like on the no-Js notifications page

Screenshot 2019-06-07 17.41.48.png (1×2 px, 432 KB)

Potentially we could actually change this notification also for the Js-enabled users.

Happy to hear your thoughts about it!
And in case I'm missing something about the no-Js possibilities I'll be happy to review my proposal.


Specifications:

  • All banners will feature
    • Home illustration to make the banner visually attractive, while reinforcing the main content == the homepage discovery
    • An "X" icon in the top right corner of the banner to dismiss it.
      • Color would be colorGray7 (or #72777d)
    • Banners will have a border: 3px solid #EAF3FF
    • Banners will have border-radius: 4px
  • Scenario A: After account creation, user chooses to go to Homepage
    Screenshot 2019-07-15 13.21.56.png (1×2 px, 560 KB)
    • Banner header text: "Welcome to your homepage!"
      • Color would be colorGray2 (or #222222)
    • Banner text: "You can always click [avatar + username] at the top of the page to return here."
      • [username] will be preceded by the user avatar icon (in-line), and should never be hyphenated.
        • Color would be colorGray7 (or #72777d)
  • Scenario B: After account creation, user chooses to go back to original context, or user abandons the survey
    Screenshot 2019-07-15 13.22.57.png (1×2 px, 1 MB)
    • Banner header text: "Thanks for creating your account!"
      • Color would be colorGray2 (or #222222)
    • Banner text: "Click [avatar and username] at the top of the page to visit your homepage and get started."
      • [username] will be preceded by the user avatar icon (in-line), and should never be hyphenated.
        • Color would be colorGray7 (or #72777d)

Here is the svg file of the Home illustration:

Mockups are up-to-date on Zeplin for more specific alignment details.

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

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

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

  • sitenotice banner shown on Js-enabled
    Screenshot 2019-06-10 17.10.41.png (1×2 px, 1 MB)
  • sitenotice banner NOT shown on no-Js
    Screenshot 2019-06-10 17.10.44.png (1×2 px, 1 MB)

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?
  • 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.
        Screenshot 2019-06-24 18.07.24.png (1×2 px, 554 KB)
  • 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
        Screenshot 2019-06-24 18.13.07.png (1×2 px, 1 MB)

@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?
MMiller_WMF moved this task from 🧐Needs PM Input to 💪In Progress on the Growth Design board.

Thanks, @Cntlsn. I think this generally sounds good. I see that the no-JS solution is the same as the mobile solution in T224883, but with different copy. Therefore, my comments below apply to both tasks. We may want to merge these tasks later.

  • I think the banner should have no clickable CTA, because we want the user to click their personal tools link to get to their homepage.
  • But that brings up my biggest concern -- that the banner will seem like it has a call to action in it, given that it showing a blue link in the middle of a sentence. I think users will try to click it no matter how we phrase the sentence. Is there a way to show, like, a "screenshot" of the username in its context in the personal tools bar, perhaps on the side of the banner? And then exclude the username itself from the sentence. This is relevant for mobile, too.
  • In terms of aggressiveness, I think the banner should only be shown once. If they navigate to another page or dismiss the banner, we should not show it anymore. We can re-evaluate this if we remain unsatisfied with homepage discovery rates in the future.
  • Is the house graphic finalized? Or does that need additional review on the design team?

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
    Screenshot 2019-07-08 17.31.39.png (1×2 px, 568 KB)
  • 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
    Screenshot 2019-07-08 17.32.48.png (1×2 px, 1 MB)

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.

MMiller_WMF moved this task from 🧐Needs PM Input to 🔥To Do on the Growth Design board.

Thanks, @Cntlsn. Below is the copy I think we need. This is ready to be turned into specifications in the description and put in Ready for Development.

Scenario A: After account creation, user chooses to go to Homepage

Header: "Welcome to your homepage!"
Text: "You can always click [avatar and username] at the top of the page to return here."

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

Header: "Thanks for creating your account!"
Text: "Click [avatar and username] at the top of the page to visit your homepage and get started."

Cntlsn removed a project: Growth Design.

The specifications have been updated, so I'm moving the task in "Ready for development".

@MMiller_WMF thanks for your comments.
As per my comment on T224883#5332504 I have a feeling that the copy for Scenario B is a bit generic and might be a missed opportunity to tell more about the Homepage (I received critics in other mockups about what the user would be getting started with if we leave it that open), but I'm ok with that.

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

kostajh renamed this task from Homepage: homepage discovery for no-JS users to Homepage: homepage discovery for no-JS users (desktop).Jul 29 2019, 6:48 AM

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:

image.png (77×300 px, 6 KB)

Does this happen to you?

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

image.png (77×300 px, 6 KB)

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

Screen Shot 2019-09-18 at 3.03.05 PM.png (550×1 px, 119 KB)

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.

Screen Shot 2019-09-18 at 3.39.31 PM.png (506×1 px, 146 KB)

Note: The Echo Welcome notification is unchanged.

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

Screen Shot 2019-09-18 at 3.03.05 PM.png (550×1 px, 119 KB)

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.

Screen Shot 2019-09-18 at 3.39.31 PM.png (506×1 px, 146 KB)

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

image.png (348×1 px, 51 KB)

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

image.png (348×1 px, 51 KB)

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

image.png (938×1 px, 185 KB)

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.

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.

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.

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:

BeforeAfter
Screen Shot 2019-09-18 at 3.03.05 PM.png (550×1 px, 119 KB)
Screen Shot 2019-10-02 at 2.22.48 PM.png (181×1 px, 32 KB)
Screen Shot 2019-10-02 at 2.28.29 PM.png (181×1 px, 35 KB)

The properties:

Screen Shot 2019-10-02 at 2.23.12 PM.png (158×432 px, 28 KB)
Screen Shot 2019-10-02 at 2.23.03 PM.png (173×499 px, 32 KB)

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

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

BeforeAfter
Screen Shot 2019-09-18 at 3.03.05 PM.png (550×1 px, 119 KB)
Screen Shot 2019-10-02 at 2.22.48 PM.png (181×1 px, 32 KB)
Screen Shot 2019-10-02 at 2.28.29 PM.png (181×1 px, 35 KB)

The properties:

Screen Shot 2019-10-02 at 2.23.12 PM.png (158×432 px, 28 KB)
Screen Shot 2019-10-02 at 2.23.03 PM.png (173×499 px, 32 KB)

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!

Artboard.png (351×447 px, 41 KB)

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.