before sharing design explorations let's look at the current navigation elements on the page, on both mobile and desktop.

mobile web / minerva neue

for logged-in people, the current interface is composed by the top navigation:

• on the right
  • main menu
  • logo
• on the left
  • search
  • notifications
  • account menu

and the article toolbar (which includes languages, bookmark/watch, history, edit, and contextual menu)

if the person is a newcomer, on pages defined on community config, we also display a floating help button in the bottom right corner.

as usual, everything is flipped if the ui language is RTL.

desktop / vector 2022

on larger vieports there are a few flowing elements based on the available space. if the 'main menu' and the 'tools' menu are open the top navigation includes:

• on the left
  • logo
  • search
• on the right
  • username
  • appereance
  • alerts
  • notices
  • saved pages
  • watchlist
  • account menu / personal settings

when the main menu is collapsed, it's displayed as a so-called hamburger menu next to the logo. when the tools menu is collapsed is displayed as a contextual menu in the article toolbar.

when the viewport is narrower the menus are collapsed automatically, and the search is collapsed too. icons are also more spaced out.

when you scroll we display a sticky nav.

and when you scroll on a narrow viewport we display the 'contents' as a floating button in the top left corner.

background

the way people can get back to their newcomer homepage today (and home tomorrow) is via their username. on mobile they need to tap on the account menu, and then tap on their username. on desktop they simply need to tap on their username in the top right nav.

during onboarding, post account creation, the system displayes a navigation/edu banner. but this information is competing with several other things on the page, and newcomer need to digest everything at once.

on T432921: Account setup: Move homepage navigation banner to first article page visit after homepage (DE1.3.1) we're considering changing the timing of this navigation/edu banner.

one of the critical aspects that we've identified during research is that we don't fully embrace how people come back to the wikis, after their first experience with the newcomer homepage. for instance, once someone comes back via a search or similar there is nothing there that reminds them that they have a home on the wikis. the only affordance that signals that they are logged-in is the user menu/icon on mobile

early proposals

mobile web / minerva

given that Reader Growth Team is running a few experiments on mobile web (and the minerva skin), we might consider a first "indipendent" proposal where we display a floating home button. visual design is still in flux.

for pages that also feature the help button, the floating buttons will be displayed side by side. layout and style still in flux.

desktop / vector 2022

on deskop we might consider 2 options, whether we want to extend the top nav bar, or explore a more "indipendent" approach.

top nav bar

within the top nav bar, we could display a home button next to the logo.

and given that real estate is already limited, we might consider moving the username inside the account menu/personal settings now that is "less" needed.

worth considering that on narrower viewports (or when the main menu is collapsed) we may end up in a situation where we have the home button next to the menu button.

floating button

alternatevely, we might consider echoing the mobile appraoch on desktop too. layout and visual design still in flux.

@Sneha and @AAlhazwani-WMF met and finalized the proposals for the home navigation experiment. these proposals need to be reviewed by growth and REx pms and tech leads.

note: each prototype link opens a preset, and the preset URL is the source of truth for that variant. the main menu opens a playground to tweak the variants, but a tweaked URL no longer matches the spec. in the prototypes the help button shows on Help:, Wikipedia: and User: pages, as a stand-in for the community configuration linked below.

mobile web / minerva

so, to start let's set some shared grounding, let's look at the experience in production.

production / control

prototype: https://aminalhazwani.github.io/protowiki3/pr-preview/pr-8/T435429?user=new&preset=production-mobile
prototype (with help button): https://aminalhazwani.github.io/protowiki3/pr-preview/pr-8/T435429?user=new&preset=production-mobile&article=Help:Reverting

1. to access their newcomer homepage new accounts need to tap on the user button, open the menu and tap on their username.
2. the top nav bar is displayed at the top of the page, and on scroll it goes away (and on scroll up it doesn't show up)
3. when newcomers navigate to their homepage we display 'Homepage', 'User page', and 'Talk' side by side as mediawiki tabs
4. when newcomers navigate to a page under a namespace that can feature the help button (https://en.wikipedia.org/wiki/Special:CommunityConfiguration/HelpPanel#GEHelpPanelReadingModeNamespaces), we display a custom floating help button in the bottom right corner

and now the treatments for the experiment.

treatment 1

prototype: https://aminalhazwani.github.io/protowiki3/pr-preview/pr-8/T435429?user=new&preset=treatment-1-mobile
prototype (with help button): https://aminalhazwani.github.io/protowiki3/pr-preview/pr-8/T435429?user=new&preset=treatment-1-mobile&article=Help:Reverting

1. to access their newcomer homepage new accounts can tap the 'home' floating button* in the bottom right corner. the top nav bar and the user menu stay as is, but if newcomers tap their username they now navigate to their user page (in production it takes them to their homepage).
2. on scroll down the home button slides out of the viewport.
3. on scroll up the home button slides back into the viewport. at the top of the page it's always visible.
4. when newcomers navigate to their home** we display the mediawiki tabs side by side. the home button is not visible on this page.
5. pages that feature the help button will display both the home and help button* side by side, with help nearest the corner. both slide out and in together on scroll.

*visual design and styling are still in flux, we can finalize this as we implement this. the prototype waits for 16px of scrolling before it hides or shows the button, slides in 250ms, and fades instead of sliding when reduced motion is on. once we start implementation we also need to define the interaction with other bottom sticky/fixed elements beside the home and help buttons.
**home designs are still in flux, we will finalize this separately from this scope

treatment 2

prototype: https://aminalhazwani.github.io/protowiki3/pr-preview/pr-8/T435429?user=new&preset=treatment-2-mobile
prototype (with help button): https://aminalhazwani.github.io/protowiki3/pr-preview/pr-8/T435429?user=new&preset=treatment-2-mobile&article=Help:Reverting

1. to access their newcomer homepage new accounts can tap the 'home' button in the top nav bar that is displayed instead of the notifications button. the username in the user menu takes them to the user page.
2. inside the user menu we add a new 'notifications' menu item, between 'talk' and 'sandbox'. when there is a new notification we display a badge number on top of the user button, and next to the notifications menu item too. with no new notifications there is no badge. count logic is equivalent to the current logic in production.
3. the top nav bar is displayed at the top of the page, and on scroll it goes away (and on scroll up it doesn't show up)
4. when newcomers navigate to their home we display the mediawiki tabs side by side
5. pages that display the custom help button remain as is (no floating home button)

desktop / vector 22

as for mobile web/minerva let's look at the production experience on desktop.

production / control

prototype: https://aminalhazwani.github.io/protowiki3/pr-preview/pr-8/T435429?user=new&preset=production-desktop
prototype (with help button): https://aminalhazwani.github.io/protowiki3/pr-preview/pr-8/T435429?user=new&preset=production-desktop&article=Help:Reverting

1. to access their newcomer homepage new accounts need to click on their username link in the top nav bar. the top nav bar is displayed at the top of the page and on scroll it goes away. once people scroll past the page title the system displays a sticky header.
2. when newcomers navigate to their homepage we display 'Homepage', 'User page', and 'Talk' side by side as mediawiki tabs
3. when newcomers navigate to a page under a namespace that can feature the help button (https://en.wikipedia.org/wiki/Special:CommunityConfiguration/HelpPanel#GEHelpPanelReadingModeNamespaces), we display a custom floating help button in the bottom right corner

treatment 1

prototype: https://aminalhazwani.github.io/protowiki3/pr-preview/pr-8/T435429?user=new&preset=treatment-1-desktop
prototype (with help button): https://aminalhazwani.github.io/protowiki3/pr-preview/pr-8/T435429?user=new&preset=treatment-1-desktop&article=Help:Reverting

1. to access their home newcomers can click on the new 'home' button that is displayed instead of their username link. to signal which account people are logged in with, we display the first one or two letters of their username as the menu button (screen readers announce the full username). the link to their user page is displayed as the first item (their username) of said menu.
2. when newcomers navigate to their home we display the mediawiki tabs side by side.
3. pages with a help button stay as is

treatment 2

prototype: https://aminalhazwani.github.io/protowiki3/pr-preview/pr-8/T435429?user=new&preset=treatment-2-desktop
prototype (with help button): https://aminalhazwani.github.io/protowiki3/pr-preview/pr-8/T435429?user=new&preset=treatment-2-desktop&article=Help:Reverting

1. to access their home newcomers can click on the new 'home + username' button that is displayed instead of their username link (screen readers announce 'username, Home'). the user menu stays as in production, so their user page is reachable via the 'User page' tab on home.
2. when newcomers navigate to their home we display the mediawiki tabs side by side.
3. pages with a help button stay as is

open questions

1. after a discussion, we decided to keep the mediawiki tabs on home for now (and reduce variables/complexities at play). any concern with this decision?
2. do we want to make an exception to the rule, and display the home button in the sticky header? (none of the treatments do today)
   
3. will this experiment run before or after the home november release? this also decides where the home button links to: Special:Homepage or the new home.
4. how is this experiment going to coordinate with upcoming experiments or design changes to the skins?
5. do we need to mark home as a private page like we do for 'saved pages'?
6. onboarding / discovery materials: based on the outcome of our conversation with pms and tech leads we might need to design educational materials to support discovery of the treatment groups. sharing the current materials as example.
   
   
7. who is enrolled: newly created accounts only, or also existing newcomers? what about autocreated and temporary accounts? we would suggest to keep experienced editors are out of scope for this experiment, how does that sound?
8. is 'treatment 1' (and 'treatment 2') the same bucket on desktop and mobile? if so, is pairing desktop treatment 1 (home in the top nav bar) with mobile treatment 1 (floating home button) intended?

will this experiment run before or after the home november release?

My vote would be after so that we can focus our efforts on getting the pilot launched in November. We're about to enter October and still have work to do to enable that (T438414) and if we hit December we'll be stuck until January.

do we need to mark home as a private page like we do for 'saved pages'?

My feeling is no, because the user isn't curating anything there - a saved pages list could conceivably be something that's public, but I don't think the same mental model applies to an interface that is clearly personalised to you.

I've seen treatment 1 and treatment 2 highlighted. Does this imply that we'll do an A/B/C experiment?

Thanks for the thorough summary of ideas and designs!

after a discussion, we decided to keep the mediawiki tabs on home for now (and reduce variables/complexities at play). any concern with this decision?

I'm in support of attempting to isolate the changes we test, so no concern from me.

do we want to make an exception to the rule, and display the home button in the sticky header? (none of the treatments do today)

I can see an argument either way. To limit icon-overload and isolate changes, we might want to stick with Home appearing under the user icon upon scroll (the current Homepage behavior on desktop for newcomers).

will this experiment run before or after the home november release? this also decides where the home button links to: Special:Homepage or the new home.

This test should wait until after the November release.

how is this experiment going to coordinate with upcoming experiments or design changes to the skins?

TBD. @SherryYang-WMF - will your team's upcoming experiments impact logged in account holders, or just logged out Readers?

do we need to mark home as a private page like we do for 'saved pages'?

I don't think so, but maybe there are other ways to convey this in a more subtle way. Or perhaps once Home is more personalized, users will understand this intuitively without need for explanation.

who is enrolled: newly created accounts only, or also existing newcomers? what about autocreated and temporary accounts? we would suggest to keep experienced editors are out of scope for this experiment, how does that sound?

• I agree that we need to keep experienced editors out of this experiment.
• I would love to include all account holders who have this setting enabled: Default to newcomer homepage from username link in personal tools
• Temp Accounts don't currently have the Homepage. We should exclude them from this experiment.
• I think we might need to tackle autocreated accounts in a different release or experiment. I'm pretty sure if they were included in the treatment, but not in the control, then we would end up with a Sample Ratio Mismatch.

is 'treatment 1' (and 'treatment 2') the same bucket on desktop and mobile? if so, is pairing desktop treatment 1 (home in the top nav bar) with mobile treatment 1 (floating home button) intended?

I think we need to scope this back for the first iteration. For a first test, we might want to consider ONLY testing a change in mobile navigation.

I've seen treatment 1 and treatment 2 highlighted. Does this imply that we'll do an A/B/C experiment?

I think that's TBD after discussion with engineers. Yes, I would love to test more than one design, but I also know we need to reduce scope if we hope to release sooner. (And the more variants the longer the test needs to run).

confirming both the image carousel retest and semantic search test coming up will impact only logged-out readers