Page MenuHomePhabricator

Homepage: homepage discovery for no-JS users (desktop)
Open, Needs TriagePublic

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


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
    • 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
    • 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

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

Also, I want to clarify about the Echo notification that @Cntlsn recommends. Is that "Welcome to Wikipedia" notification something that we configure? Or that wikis configure? Do all wikis have it?

@Catrope @MMiller_WMF
About the banners in the sitenotice area, the reason why I opted for not relying on those is that 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

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

Cntlsn added a comment.EditedJun 13 2019, 3:27 PM

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?
JTannerWMF moved this task from Needs triage to Triaged on the Mobile board.Jun 14 2019, 11:36 AM
  • 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.

Cntlsn added a comment.EditedJun 19 2019, 10:11 AM
  • 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?
MMiller_WMF assigned this task to Cntlsn.Jul 3 2019, 8:46 PM
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?
Cntlsn added a comment.EditedJul 8 2019, 4:10 PM

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.

Cntlsn reassigned this task from Cntlsn to MMiller_WMF.Jul 10 2019, 5:14 PM
Cntlsn moved this task from 💪In Progress to 🧐Needs PM Input on the Growth Design board.
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 updated the task description. (Show Details)Jul 15 2019, 11:31 AM
Cntlsn removed Cntlsn as the assignee of this task.Jul 15 2019, 11:34 AM
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

leila removed a subscriber: leila.Jul 29 2019, 5:41 PM

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

MMiller_WMF updated the task description. (Show Details)Aug 1 2019, 7:02 PM

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?

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