Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Page MenuHomePhabricator

AMC Navigation - add new links to main menu with click tracking
Closed, ResolvedPublic5 Estimated Story Points

Description

User Story

As an advanced editor, I want the ability to access useful pages quickly. Demo here.

Description

We will be adding several items to the menu.

Acceptance criteria

  • The changes will be AMC only. There will be no changes to stable. (this is the default for all AMC tasks, unless explicitly marked otherwise)
  • The main menu will contain the following pages:
    • Main page
    • Nearby
    • Random
    • ------------------------
    • User page/logout
    • Watchlist
    • Contributions
    • ------------------------
    • (+) Recent changes
    • (+) Special pages
    • (+) Community portal
    • ------------------------
    • Settings
  • The community portal URL is customisable. It should be loaded from the message MediaWiki:Portal-url. If the message doesn't exist, do not show it.
  • The "Contributions" icon will be updated to use the article icon (for all users, including non-AMC)
  • There is a feature flag and these are disabled by default in amc, stable and beta (a separate task will enable them once we've QAed and verified the instrumentation to be working).
  • All links added to the main menu have a unique data-event-name in MobileWebMainMenuClickTracking (no schema modification needed), for the following:
  • (+) Recent changes event-name="recentchanges"
  • (+) Special pages event-name="specialpages"
  • (+) Community portal event-name="community-portal"

Designs

fulliOSAndroid
full.png (1×750 px, 138 KB)
iOS.jpeg (1×750 px, 234 KB)
Screenshot_20190221-123258.png (2×1 px, 228 KB)

Design notes

  • Currently the Contributions icon in the menu is the same as the History icon. Let's switch it (for all users) to the article icon.
  • If it makes sense we should consider updating the UX of the menu based on T206354

Developer notes

Eventually, in conjunction with T214540, we will be removing the user items (User page/logout, Watchlist, Contributions) so don't worry about duplication.

Click tracking is pretty straightforward -since we are only adding links to the MainMenu we get it for free simply by adding a data-event-name attribute to the links we add.

All links are hardcoded, except the community portal. This is defined via https://en.wikipedia.org/wiki/MediaWiki:Sidebar

Two menus (AMC and non-AMC)

Menu data is shipped to the client in mw.config.get('wgMinervaMenuData') and for AMC this will not be cached so there should be no caching worries if we need to maintain 2 menus. The MenuBuilder class is pretty flexible; here's an example:

$menu->insert( 'contribs' )
                        ->addComponent(
                                $this->msg( 'mobile-frontend-main-menu-contributions' )->escaped(),
                                SpecialPage::getTitleFor( 'Contributions', $user->getName() )->getLocalUrl(),
                                MinervaUI::iconClass( 'contributions', 'before' ),
                                [ 'data-event-name' => 'contributions' ]
                        );

No JS/CSS changes should be necessary when adding a new group.

Analytics

  • MainMenuClickTracking schema ID exists in MobileFrontend. We should move that to Minerva as this is confusing. But apart from that, all code is in Minerva.
  • All the code for communicating with EventLogging lives in Minerva resources/skins.minerva.scripts/menu/schema.js
  • 50% of clicks in the main menu are sampled (Per wgMinervaSchemaMainMenuClickTrackingSampleRate)
  • Every link inside the MainMenu will be logged provided it has a event-name value (see resources/skins.minerva.scripts/menu/MainMenu.js)

QA steps

Verify events show for all the newly added items, but also the existing items.
New menu can be tested on staging env: https://reading-web-staging.wmflabs.org/wiki/Main_Page

  • Main page
  • Nearby
  • Random
  • User page/logout
  • Watchlist
  • Contributions
  • Settings

Sign off steps

QA Results

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdlrobson moved this task from Needs Prioritization to Upcoming on the Web-Team-Backlog board.

Sampling problem is now captured in T218627. This task is ready for estimation.

Change 502278 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/skins/MinervaNeue@master] Provide a code structure for menus handling

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

Change 502547 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/skins/MinervaNeue@master] Add Community Portal link to Mobile Main Menu

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

Change 502869 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/skins/MinervaNeue@master] Use MediaWikiServices to cache commonly used helpers

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

Change 502905 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/skins/MinervaNeue@master] Extract SkinOptions to separate class

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

@ovasileva I have a question regarding the Community portal menu entry. Link for that menu entry comes from MediaWiki:Portal-url page. Usually, it has a Title (something like Wikipedia:Community portal), but it is possible, that this page will have an absolute link: (something like https://test.com/link). Therefore (when it's a link), we cannot get the menu entry label. By default, the label is the page name (which is also localized -- translated to user language). For absolute links, we can add a fallback translation, but most probably it will not be used as most probably all wikis definte Portal-url as a Title.

I don't know if this is a real problem on wikis, what I'm saying "There is a possibility that Community Portal links outside and we cannot get menu entry label for that link". What should we do? I see two possibilities:

  • Ignore it if this is an URL to external site. The menu entry "Community Portal" will not be visible
  • Link to external site, use a fallback translation for "Community Portal
  • Ignore it if this is an URL to external site. The menu entry "Community Portal" will not be visible

@pmiazga - to confirm, it would be visible when it's an internal link? If so, let's go for this option.

  • Ignore it if this is an URL to external site. The menu entry "Community Portal" will not be visible

@pmiazga - to confirm, it would be visible when it's an internal link? If so, let's go for this option.

It will be visible when it's a Title - something like Namespace:Title, for example: Wikipedia:Community Portal or Project:Community.
But if it's a link, for example, if on English Wikipedia someone defines Portal-url to http://en.wikipedia.org/wiki/Project:Community it won't be visible (even its links to the same page internal page). The problem is that I'm not sure if we have tools to parse links, if not then we have to manually detect the host (does it point to the same wiki), then it has to extract Title name, try to search if that Title exists. It's just safer and faster to ignore it when it's a link, and handle only Titles.

I checked like 10 wikis, all defined Title. We should be fine, this is an edge case that (I hope) is supported but not used.

  • Ignore it if this is an URL to external site. The menu entry "Community Portal" will not be visible

@pmiazga - to confirm, it would be visible when it's an internal link? If so, let's go for this option.

It will be visible when it's a Title - something like Namespace:Title, for example: Wikipedia:Community Portal or Project:Community.
But if it's a link, for example, if on English Wikipedia someone defines Portal-url to http://en.wikipedia.org/wiki/Project:Community it won't be visible (even its links to the same page internal page). The problem is that I'm not sure if we have tools to parse links, if not then we have to manually detect the host (does it point to the same wiki), then it has to extract Title name, try to search if that Title exists. It's just safer and faster to ignore it when it's a link, and handle only Titles.

I checked like 10 wikis, all defined Title. We should be fine, this is an edge case that (I hope) is supported but not used.

That sounds fine to me - just looked at a few wikis too. Let's hide it if it's a link.

@ovasileva @pmiazga @Jdlrobson after looking at @Tbayer's research again, and consulting with @CKoerner_WMF, I think we should consider including Logs (Special:Logs) and Articles for deletion (Wikipedia:AfD) in the main menu for AMC users.

Why we should consider these pages for inclusion:

  • They both appear in the top 20 most used "special" (e.g. non-mainspace pages) for large wikis. Keep in mind that with our AMC designs we already offer 8 of the 10 most popular special pages (using en.wiki data as a reference), so finding additional special pages that appear in the top 20 across multiple wikis isn't so common.
  • They both meet the general requirement of working well on mobile (no additional styling needed)
  • The associated workflows are able to be completed on mobile
  • As a general note: our current plan is to add 3 items to the menu, so adding an additional 2 is possible without the menu getting crowded
Logs

Popularity ranking among wikis (of non-mainspace pages)

enitjaptesidar
13131217161527

What makes it questionable:
It's unclear with the current data if it is common for someone to visit Logs directly, or if it's more common to get there via a userpage. We will already include a link to Logs in the overflow menu on userpages. @CKoerner_WMF @Tbayer @TheDJ @kaldari any assumptions you can add here?

Articles for deletion

Popularity ranking among wikis (of non-mainspace pages)

enitjaptesidar
566522X42

What makes it questionable:
The value of this page is heavily skewed towards large wikis. Presumably when you are small you are much more focused on creating articles than deleting them. Secondly, it is a bit confusing to me if there is a common AfD page among wikis, or if there is some variation. For example, if you navigate from Wikipedia:AfD to the equivalent page on es.wiki, you land on Wikipedia:Consultas de borrado mediante argumentación, which does not even appear in Tilman's data. The page that is used in Spanish for AfD is Categoría:Wikipedia:Consultas de borrado, however if from there you navigate to the equivalent page on en.wiki, you do indeed land at AfD. It seems there is not a direct 1:1 relationship for these pages among wikis. I am not particularly familiar with how these pages get linked, though it does raise some concern around the difficult of including one link in the menu and making sure it leads editors of their respective wikis to the appropriate page.

Mockup for reference

mobile-contributions.firebaseapp.com_nav4-side-nav.html(iPhone 6_7_8).png (1×750 px, 135 KB)

Other remarks

This investigation helped build the case, at least for myself, that allowing wikis to customize which items appear in the main menu (and potentially other menus) would be beneficial. I imagine even having two menus, one for large wikis and one for small, would be a worthwhile investment.

Logs are either page contextual or user contextual. For user contextual, i'd expect to reach them either in the same way as the user action 'contributions or possibly via the contributions page itself (though that might be more for logged actions BY the user, instead of 'about the user')'. For articles the action is at a similar level as the page history.

AfD seems highly difficult to me to harmonize across the various wikis. It's also not as relevant in my view as you might think as people tend to visit AfD from the messagebox linked of the article nominated for deletion.

However, you might consider building a sub menu or something where communities can list their own links to 'community processes' or something. Perhaps manage it in a similar way as MediaWiki:Sidebar and have MediaWiki:Sidebar-section-process or something. Then other skins could also use such a menu definition. I think any skin specific menu definition that is not defineable via a MediaWiki message or something similar is probably a bad idea (cause doesn't scale to smaller communities, as we have seen from past Mobile main page definitions).

I checked like 10 wikis, all defined Title. We should be fine, this is an edge case that (I hope) is supported but not used.

Generally the link methodology is only used when query parameters need to be specified or something. It's pretty rare.

Change 502869 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Use MediaWikiServices to cache commonly used helpers

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

Change 502905 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Extract SkinOptions to separate class

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

@TheDJ the new MainMenu implementation still sticks to old way of having MainMenu entries defined/hardcoded in the MinervaNeue. But now, it will be much easier to change it/override it. Menu building is finally fully configurable, and the only required thing is a new class, sth like WikiSourcedMainMenu that implements Menu/Main/IBuilder. That class would have to fetch the WikiPage, parse it, and return Groups[] set based on the wiki page. Previously such change wasn't available, now, finally, it should be possible to do. The only thing is how to tackle user-related entries (like login/log out buttons),

Change 502278 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Provide a code structure for menus handling and add Advanced menu

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

Change 502547 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Add Community Portal link to Mobile Main Menu

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

@alexhollender - Personally, I never go directly to Special:Logs. It's almost always from a user or page specific link (with preset query parameters). It's not a terrible idea though. Putting Wikipedia:ArticlesForDeletion in the sidebar seems a bit strange, though. What would be more useful, IMO, would be having Special:MovePage in the sidebar, as otherwise it is quite difficult to move a page manually on mobile: you have to manually go to Special:MovePage, and remember the exact title of the page you wanted to move, which is often tricky if you're moving the page due to a misspelling or bad title. There should be a way to reach Special:MovePage directly from the article context (and have the title pre-filled as it is on desktop). This may not be a commonly visited special page, but it provides an essential function.

For this iteration, let's remove the recent changes link as well - we'll move it back in when the recent changes page is ready.

Change 504938 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/skins/MinervaNeue@master] Remove Recent Changes from Main Menu

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

https://gerrit.wikimedia.org/r/504938 removes The recent changes link from Advanced menu. If we decide to put Recent changes link once again, please revert this patch.

From the Task description:
  • The community portal URL is customisable. It should be loaded from the message MediaWiki:Portal-url. If the message doesn't exist, do not show it.

Note that this will cause the link to show up on some wikis in a way that points to a 404 Not Found. This message is part of the MediaWiki software, which means it will always exist - even if the specified page name does not.

The way it currently works is that wikis opt out or disable it by removing the reference from MediaWiki:Sidebar.

@Krinkle we load the MediaWiki:Portal-url, and then verify if title exists -> if the page doesn't exist we do not show the link - https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/master/includes/menu/Definitions.php#L323

Change 504938 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Remove Recent Changes from Main Menu

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

@Krinkle we load the MediaWiki:Portal-url, and then verify if title exists -> if the page doesn't exist we do not show the link.

Makes sense. Note that this is still distinct from what core defines and what communities may expect. It's close enough that it might go unnoticed at first, but will likely cause confusion, incompatibilities and frustration long-term because it currently offers users no way to fix it.

There isn't an easy way to make everything work. But I've listed a few minimal things below that I think would allow us to cover most use cases.

From comparing Minerva/Menu/Definitions::insertCommunityPortal to Skin::buildSidebar.

  • The Minerva code interacts with the internal MessageCache directly, bypassing the Message class. As such, this means on multi-lingual wikis, it will not correctly swap content-language for user-language. (E.g. on Commons, the sidebar is localised by user instead of content language). This can be fixed by using Message::inContentLang::plain instead of MessageCache::get(…, content=true).
  • The core parsing of a sidebar -url message includes logic for handling -, which means "disable this link". In Minerva, it think it would now present a link to the article "Hyphen-minus". This can be fixed by replacing the current !$title check (which is an anti-pattern in PHP for strings, because it rejects valid strings like '0'). The core code explicitly checks the three values that should be used here: false, (empty string) and dash. You can use use $msg->isDisabled() to get these behaviours without duplication of code.
  • The core parsing of a sidebar link, includes a secondary message for the label of the link. The Minerva code currently seems to hardcode a temporary assumption that happens to match English Wikipedia, which is to take the textual portion of the link title destination ("Community portal" in "Wikipedia:Community_portal"). I think users expect to be able to localise this separately. To avoid users having to resort to awkward hacks involving redirect to make titles become labels, this can be fixed by using using the MediaWiki:Portal interface message for the label, matching core.

There are likely more differences, but I think these three are the most important and will allow users to address any differences that come up. For example, today on desktop, enablement of a link is represented by removing the bullet point from MediaWiki:Sidebar. It's not unlikely a user may have created the portal page at some point in the last 10 years, but no longer used. This means MediaWiki:Portal-url does not exist, and is not listed at Sidebar, but the default message value refers to a page that technically exists. With the above recommendations, users could fix this by placing - in Portal-url, which seems easy enough and hopefully a reasonable compromise (perhaps worth mentioning in Tech-News for awareness).

@Krinkle thanks for your input. When building Definitions::insertCommunityPortal I found the code that was doing almost the same what I needed. That's how the insertCommunityPortal() was made. I'll check it with Skin::buildSidebar() and update the code.

@TheDJ thanks for your thoughts. Mainly out of curiosity - do you know why there isn't a link to Logs in the Tools menu in Vector when viewing an article? There is one when viewing a user page.

image.png (710×1 px, 642 KB)

@kaldari thanks for your thoughts and the suggestion about Move. We've discussed it in the past. I will double check that we have that tracked somewhere.

Change 506842 had a related patch set uploaded (by Pmiazga; owner: Pmiazga):
[mediawiki/skins/MinervaNeue@master] Improve Community Main Menu element handling

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

Change 506842 merged by jenkins-bot:
[mediawiki/skins/MinervaNeue@master] Improve Community Main Menu element handling

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

In T216152#5127810, @alexhollender wrote:

@TheDJ thanks for your thoughts. Mainly out of curiosity - do you know why there isn't a link to Logs in the Tools menu in Vector when viewing an article? There is one when viewing a user page.

image.png (710×1 px, 642 KB)

The link on user pages is a sibling to "User contributions" (also shown on user pages only, not on articles). Both this and "Logs" are currently used with the performing user as the default filter.

However, comparison to user pages aside, it might indeed be useful to have "Logs about this page" be (in)directly discoverable by users from the read mode. This is currently fulfilled via the history page. ReadView historyView logs for this page. There are quite a lot of miscellaneous tools that we only offer via the top navigation of a secondary page, instead of "prime time" on the article sidebar. See also the top nav on "Special:Contributions". F28943250. I'd be interested to see whether we could streamline this.

At that point we may need to also figure out whether to keep "History" as a tool, or as a view mode. I imagine that from a user's perspective, "Revision history" and "Page logs" are not very different, so having them in different places might be more confusing than today where one is bound to the other.

Logs traditionally was also very much an 'advanced' thing. It has become a lot more important in the past 10 years however, as we started logging more and more events also of and for lower level users.

Edtadros subscribed.

Test Result

Status: ✅ PASS
OS: macOS Mojave
Browser: Chrome
Device: MBP
Emulated Device: iPhoneX

Test Artifact(s):

QA Steps

Verify events show for all the newly added items, but also the existing items.
New menu can be tested on staging env: https://reading-web-staging.wmflabs.org/wiki/Main_Page

✅ AC1: Main page

Screen Shot 2019-05-14 at 6.51.04 PM.png (510×3 px, 147 KB)

✅ AC2: Nearby

Screen Shot 2019-05-14 at 6.53.23 PM.png (510×3 px, 170 KB)

✅ AC3: Random

Screen Shot 2019-05-14 at 6.54.14 PM.png (556×3 px, 155 KB)

✅ AC4: User page/logout

Screen Shot 2019-05-14 at 6.55.24 PM.png (516×3 px, 176 KB)

Screen Shot 2019-05-14 at 6.56.13 PM.png (508×3 px, 177 KB)

✅ AC5: Watchlist

Screen Shot 2019-05-14 at 6.56.59 PM.png (556×3 px, 187 KB)

✅ AC6: Contributions

Screen Shot 2019-05-14 at 6.58.13 PM.png (558×3 px, 170 KB)

✅ AC7: Settings

Screen Shot 2019-05-14 at 6.59.07 PM.png (516×3 px, 166 KB)

@Jdlrobson, is there a more preferred way to verifiy the event name?

All done, main menu is functional in production on arwiki, idwiki, eswiki. Resolving