Page MenuHomePhabricator

Homepage: discovery of homepage after account creation (mobile)
Open, Needs TriagePublic

Description

The objective of this task is to help more newcomers discover their homepage.
Potentially the most important time to help newcomers discover their homepage is the moment after account creation, which means after the welcome survey. The newcomer can do three things with the welcome survey: submit, skip, abandon. But no matter which of those paths from the welcome survey the newcomer takes, we still want them to discover their homepage, and we so may have to design different experiences for each path.

While working on this task for the desktop version of the Homepage (T222852) we noticed that the mobile experience might need a different design treatment as Guided tour popups might be tricky to support on different mobile screen sizes and browsers.

This task is to think about a mobile first way to address the same approaches for aiding Homepage discovery after account creation as surfaced in the matrix at T222852


Specifications:

  • All banners will feature
    • Arrow pointing to hamburger button.
      • Left margin: it will be important here to keep the margin-left consistent with hamburger button's margin, in order to always display the arrow pointing at the hamburger button, and not for instance at the "Wikipedia" logo in the header.
      • Top margin: the arrow will be aligned to the banner's header.
    • An "X" icon in the top right corner of the banner to dismiss it.
      • Color would be colorGray7 (or #72777d)
  • Users should only see one of these two banners, depending on which scenario they end up in first.
  • Users should only see the banner when it is first displayed. If they dismiss it with the "X", it goes away, never to return. If they navigate away from the page without dismissing it, they never see it again.
  • 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 open the side menu and tap [avatar + username] to return here."
      • [username] will be preceded by the user avatar icon (in-line), and should never be hyphenated.
      • Text color would be colorGray7 (or #72777d)
  • Scenario B: After account creation, user chooses to go back to their original context, or user abandons the survey. Many users will end up back in the editing context from which they created their account. Since the editing context opens as a modal, this banner would not be shown. They should see it when they finally exit the editing context and are looking at the reading context, whether they saved or abandoned their edit.
    • Banner header text: "Get started here!"
      • Color would be colorGray2 (or #222222)
    • Banner text: "Open the side menu and tap [avatar + username] to visit your homepage."
      • [username] will be preceded by the user avatar icon (in-line), and should never be hyphenated.
      • Text color would be colorGray7 (or #72777d)

Here is the svg file of the arrow illustration:

Specifications - landscape orientation and tablet:

  • Banner text:
    • text wrapper will be center aligned
    • text will also be center aligned
    • 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

Here is the svg file of the arrow illustration for landscape orientation and tablet:

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
MMiller_WMF renamed this task from Homepage: discovery of homepage after account creation on mobile to Homepage: discovery of homepage after account creation (mobile).Jun 12 2019, 4:37 PM

Thanks @alexhollender for your previous comments!

I do share the point of both your considerations, and been thinking about it in the last days. I also had the chance to talk to @schoenbaechler who showed me how the suggested edits feature is currently "advertised" to android users, and it's basically almost the exact same behavior I proposed above (https://overflow.io/s/24PSRV/?node=d26e9852).

While I think the notification dot icon could be a powerful tool to drive newcomers to the Homepage, and also think we should really be taking this discussion further to understand how to keep it there while tackling the points raised by Alex, I have decided to display banners in the site notice area of the screen, as that would let us address a couple more issues.

FYI specs follow in the comment below.

Cntlsn added a comment.EditedJun 24 2019, 6:36 PM

Taking into consideration the conversation above (and at T212280) and the approach taken in T222852, I have iterated on the proposed solution.
Instead of displaying a trail of blue dots leading to the Homepage, we will show banners in the sitenotice area of the screen addressing:

  • account success
  • what the Homepage is about
  • how to reach it

This solution doesn't necessarily exclude the previous proposal. We could potentially decide to keep them both once we sort out how to better use the dot icon visual aid, since they have different strengths (pointing exactly to the link VS giving more context details).

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 tap on [username] in the side menu to return here."
      • [username] will be preceded by the user avatar icon (in-line), and should be bold and dark grey to mimic the exact same UI composition as the one in the side menu, and let user create the association between the banner and the link to the Homepage in the side menu.
      • [username] should never be hyphenated.
  • Scenario B: After account creation, user chooses to go back to reading context, 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 "Tap on [username] in the side menu to discover your personal homepage and get started with editing."
      • [username] will be preceded by the user avatar icon (in-line), and should be bold and dark grey to mimic the exact same UI composition as the one in the side menu, and let user create the association between the banner and the link to the Homepage in the side menu.
      • [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:

  • Since we cannot show a banner on top of the mobile editor when the user decides to go back to the editing context (as the editor is displayed in a modal), would it be possible to show the banner when the user exits the original editing context?
  • 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?
Cntlsn reassigned this task from Cntlsn to MMiller_WMF.Jul 3 2019, 4:34 PM
MMiller_WMF reassigned this task from MMiller_WMF 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.

My comments on this task are combined with my comments on the no-JS task here: T225318#5304863

Cntlsn added a comment.Jul 8 2019, 4:33 PM

@MMiller_WMF Design for mobile discovery after account creation has been updated, and will differ from desktop noJs treatment (T225318) mostly for illustration content and styling. I would keep the two tasks separated to avoid confusion.

Below are iterated mocks for mobile discovery:

  • Scenario A: After account creation, user chooses to go to Homepage
  • Scenario B: After account creation, user chooses to go back to reading context, or user abandons the survey

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

Could you please double-check copy?

Also, @Catrope could you please weigh in on:

Since we cannot show a banner on top of the mobile editor when the user decides to go back to the editing context (as the editor is displayed in a modal), would it be possible to show the banner when the user exits the original editing context?

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

Also, @Catrope could you please weigh in on:

Since we cannot show a banner on top of the mobile editor when the user decides to go back to the editing context (as the editor is displayed in a modal), would it be possible to show the banner when the user exits the original editing context?

Yes, but it may require a little more effort. If the user exit the editing context by abandoning the edit, the modal goes away and reveals the banner underneath. But if they exit by saving, the page will reload, and we'll have to find a way for the banner to persist across that reload. If we make the banner "aggressive", as you called it, then this isn't a problem, because the banner would persist until explicitly dismissed anyway. But if we decide not to make it aggressive and hide it after the first view, then the banner would believe that it's been viewed already and hide itself, and we'd have to counteract that somehow.

@Catrope got it, thanks for your input.

@MMiller_WMF considering what @Catrope just said, I would keep the banners to only show once (as you also proposed on T225318#5304863), and acknowledging the fact that some users (the mobile users going back to original editing context after account creation, and saving their edit) won't receive the banner. I believe it would only be a minor fraction of our treatment groups. How do you feel about it?

MMiller_WMF added a comment.EditedJul 12 2019, 11:37 PM

@Cntlsn -- I think we should require that the mobile users who save an edit see the banner anyway. I think it will be something like 10-20% of mobile users, and they are some of the most valuable users because they have already gone through the editing cycle! They're ready to see their impact and to get task recommendations. If it becomes really difficult to do this, we can split that specific use case into a separate task.

Below is my copy for the messages, and then this is ready for you to put specifications in the task description, and move to Ready for Development.

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

Header: "Welcome to your homepage!"
Text: "You can always open the side menu and tap [avatar and username] to return here."

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

Header: "Get started here!"
Text: "Open the side menu and tap [avatar and username] to visit your homepage."

MMiller_WMF moved this task from 🧐Needs PM Input to 🔥To Do on the Growth Design board.
Cntlsn updated the task description. (Show Details)Jul 15 2019, 10:52 AM
Cntlsn removed Cntlsn as the assignee of this task.Jul 15 2019, 10:58 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.
I have a feeling that the copy for Scenario B is a bit generic and not particularly attractive, but I'm ok with that.
I will leave it to @Catrope about finding a solution for displaying the banner after edit save action, design-wise there are no changes to the banner.

Cntlsn updated the task description. (Show Details)Jul 15 2019, 11:24 AM

@Cntlsn -- I tried to align the copy as closely as I could between the mobile version, desktop no-JS version, and desktop GuidedTour version. I think that if the copy differs between them, we should have reasons for why it's different. Do you think they need to be different from each other? Or improved across the board?

@Cntlsn could you please provide landscape / tablet mockups for this task as well?

@MMiller_WMF can you please confirm that this is ready for development, per T224883#5335001? Probably the first thing to do here is submit a patch containing the translation strings, if we are going to introduce new ones.

MMiller_WMF updated the task description. (Show Details)Jul 29 2019, 8:39 PM
MMiller_WMF updated the task description. (Show Details)Jul 29 2019, 8:43 PM

@kostajh -- this is ready for development, but below, I list a couple of changes I made to the specifications, open questions I have, and things we're waiting for:

  • I added the specification that any given user should only see one of the two banners -- whichever "scenario" they end up in first.
  • I clarified that users who don't go straight to the homepage from their welcome survey should receive the banner the next time they are in a reading context. This clarification is needed because many users will end up back in the editing context, and the editor opens in a modal where the banner won't appear. For those users, we want them to see the banner once they exit the editor.
  • I added that users should only see the banner once. If they dismiss it or navigate away, they should never see it again.
  • We'll expect tablet/landscape mockups from @Cntlsn.
  • A question for @kostajh on instrumentation: in T222852#5314917, we decided that we would use the existing GuidedTour EventLogging schemas to help detect whether users end up on their homepage after seeing the GuidedTours. But these sitenotice banners wouldn't put data in those schemas. What do you recommend in terms of being able to detect whether users end up on their homepage as a result of these banners?
  • A question for @kostajh on banner rules: what will users experience if CentralNotice (or something else) is already displaying something in this sitenotice area? Will they see two banners stacked? Or will one take precedent? This is also relevant to T225318.

A question for @kostajh on instrumentation: in T222852#5314917, we decided that we would use the existing GuidedTour EventLogging schemas to help detect whether users end up on their homepage after seeing the GuidedTours. But these sitenotice banners wouldn't put data in those schemas. What do you recommend in terms of being able to detect whether users end up on their homepage as a result of these banners?

Hmm. In Scenario A they are already on their homepage. Do you mean, do they test out tapping on their username?

For Scenario B, I could imagine that the code which adds the banner to the page also sets the query string for the user avatar icon to include source=personaltoolslinkbannershown, and maybe also for Scenario A. Then in HomepageVisit schema we'd be able to see if the personal tools link was clicked from the context in which the user was shown the banner.

A question for @kostajh on banner rules: what will users experience if CentralNotice (or something else) is already displaying something in this sitenotice area? Will they see two banners stacked? Or will one take precedent? This is also relevant to T225318.

Currently we discard whatever other site notice may exist. If we should change that behavior please let us know. IMO it would be better to discard other notices as we only show our site notices in limited contexts and for a single time.

@Cntlsn should we move this to needs design until the landscape / tablet mockups are in?

Cntlsn added a subscriber: RHo.Aug 1 2019, 4:53 PM

I took some time to research about the eventuality of the new user menu for AMC Navigation T214540 to impact the experience of the features to aid discovery. More specifically in the context of the design solution proposed for this task -- where an arrow is pointing directly to the hamburger button, with textual indication about opening the side menu to look for the username (link to Homepage) -- it could have broken the experience of finding the Homepage, completely defeating the purpose of the feature.

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?

Cntlsn added a comment.Aug 2 2019, 8:49 AM

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

RHo added a comment.Aug 5 2019, 9:24 AM

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.

Cntlsn updated the task description. (Show Details)Aug 5 2019, 11:28 AM

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.

MMiller_WMF updated the task description. (Show Details)Sep 11 2019, 12:49 AM
MMiller_WMF edited projects, added Growth-Team (Current Sprint); removed Growth-Team.

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.

Tgr claimed this task.Sep 16 2019, 4:26 PM

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

narrowwidewiderwidest

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

Tgr added a comment.Thu, Sep 26, 2:56 PM

Also per comments in T225318#5526093.

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.

Tgr added a comment.Tue, Oct 1, 7:02 PM

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.

Tgr added a comment.Tue, Oct 1, 7:19 PM

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.

RHo added a comment.Tue, Oct 1, 7:59 PM

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.

Tgr added a comment.Tue, Oct 1, 10:57 PM

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

MMiller_WMF reassigned this task from Tgr to RHo.Thu, Oct 3, 12:01 AM
MMiller_WMF added a subscriber: Tgr.

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

Tgr added a comment.Tue, Oct 8, 11:23 AM

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.

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

Etonkovidova added a comment.EditedWed, Oct 16, 12:35 AM

@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