Page MenuHomePhabricator

Show Navbox templates in mobile skins
Open, LowPublic

Description

In the mobile view of a Wikipedia page the "navigation box(es)" (also known as NavBox) at the bottom of articles are not shown. I don't mean 'collapsed by default', I mean that they are literally not there at all.

This is a piece of the content of an article that is being hidden from users. [equally, article categories aren't shown, but that's a different story]. Considering that the mobile team is develping the "Related articles" feature to automatically highlight relevant further reading, it seems counterproductive to deliberately hide the manually curated collections of related content that go with many articles.

Example:
The bottom of the mobile article "The Old Vic" https://en.m.wikipedia.org/wiki/The_Old_Vic goes from the 'external links' section straight to the 'talk' and 'other languages' mobile links.
Whereas the desktop version of the same article https://en.wikipedia.org/wiki/The_Old_Vic has a "Theatres in London" navigation box (shown in a 'collapsed' state by default). https://en.wikipedia.org/wiki/Template:Theatres_in_London

The challenge

These are currently hidden from the mobile view due to the fact it is challenging with the current templates to render them nicely on mobile and the navboxes on large articles can account for 10% or the article html (which slows down load time). https://www.youtube.com/watch?v=eaos1s3UfLs documents what the experience would be if these were enabled and the collapsing JavaScript was enabled on mobile (note this is currently disabled for ux reasons given the mobile site allows collapsing of sections; the touch area of show/hide is small and not optimal for mobile).

Motivations

Outcome from 2018 SEO project with Go Fish Digital:

The navboxes at the bottom of articles are good for search engine rankings, as they improve the link equity of the other pages. This is true even if the links are collapsed by default (which they are on desktop), and also true even if the links themselves are in the HTML but not visible to the user.

Navboxes were removed from the mobile view because the nature of the tables meant they weren't very useful to users, and removing them also reduced page weight. Search engines like Google are increasingly switching to mobile-first crawling, and not having these links present is bad for link equity.

There's a tradeoff here: page weight and good performance are taken in to account by crawlers, but so is the presence of these links. If adding the links back in (but not necessarily displayed to the user) doesn't have a large performance impact, then they should probably be put back.

See also:

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Jdlrobson renamed this task from Show Navboxes in mobile view to Show Navboxes in Minerva skin (mobile view).Jul 31 2017, 5:27 PM
Jdlrobson renamed this task from Show Navboxes in Minerva skin (mobile view) to Show Navboxes in Minerva skin (mobile view and desktop).
Jdlrobson edited projects, added MinervaNeue (Desktop); removed MobileFrontend.
Jdlrobson renamed this task from Show Navboxes in Minerva skin (mobile view and desktop) to Show Navboxes in mobile skins.Aug 16 2017, 6:55 PM
Jdlrobson edited projects, added MobileFrontend; removed MinervaNeue (Desktop).

Navboxes are now showing on tablet/desktop (although look terrible) https://en.wikipedia.org/wiki/Barack_Obama?useskin=minerva so changes project to MobileFrontend but a considerable amount of redesign is needed on the templates before we can even consider showing these.

Aklapper renamed this task from Show Navboxes in mobile skins to Show Navbox templates in mobile skins.Oct 27 2017, 10:14 AM
Aklapper removed a subscriber: wikibugs-l-list.

Since it's not something that is easy to experience for most people, I made a video of what navboxes + minerva + mobile device currently look like.
https://www.youtube.com/watch?v=eaos1s3UfLs

Even if navboxes looked beautiful on mobile, I'm still not sure I would support including them. Over the years, navboxes have grown larger and larger until now they are often absurdly large directories of articles that may only be tangentially related to the article at hand:

https://en.wikipedia.org/wiki/Template:Technology
https://en.wikipedia.org/wiki/Template:Protected_areas_of_Florida
https://en.wikipedia.org/wiki/Template:Animal_rights
https://en.wikipedia.org/wiki/Template:Global_warming

Scrolling through huge templates like that on mobile is usually just a waste of time (and bandwidth).

to better suit our users on 2g connections who we believe cannot even access our site without the use of an external proxy - a more pressing issue

I will repeat here from Wikipedia:Village_pump_(technical).

2G is not completely gone, but it will decay over time

https://www.akamai.com/us/en/about/news/press/2017-press/akamai-releases-first-quarter-2017-state-of-the-internet-connectivity-report.jsp: average 2.8 Mbps in Venezuela

We cannot give Internet if they cannot have one. Better to support blind and deaf people than minorities with slow net.

Scrolling through huge templates

It is a problem with CSS. It should be 1D scrolling and not 2D scrolling

Some progress can be done with current flexboxes:

Possible version without nested navboxes: http://jsfiddle.net/mh7vqt23/11/

I'm skeptical to make it without JS at this moment.

<s>I'm stuck with "alignAsides" http://jsfiddle.net/mh7vqt23/8/ when iframe is 1280px wide: it should update asides but also to ignore asides from .flexnav-forced-column (first aside should get width of second, but not third)</s>

Even if navboxes looked beautiful on mobile, I'm still not sure I would support including them. Over the years, navboxes have grown larger and larger until now they are often absurdly large directories of articles that may only be tangentially related to the article at hand.

I would respectfully argue that this is not the issue at hand. I agree with you that there are many examples of hugely cumbersome navboxes. However, it should not be the decision of the the software developers which parts of a Wikipedia article are or are not displayed for aesthetic reasons. Working out HOW to better display thigs such as infoboxes (let alone how to edit them) is a topic of much interest and debate - but it would be 'overreach' for the developers of the mobile interface to decide that because they think infoboxes are sometimes/often cumbersome to read, that they should not be displayed to anyone.

We *should* have a discussion on-wiki for how to better utilise the value/power of navboxes. And, removing them from the mobile version for serious technical reasons is a valid argument. But, IMHO, developers should *not* be refusing to display them because of *content reasons*.

they should not be displayed to anyone

It should be a configuration option, similar to other question(s).

Like nobody knowns what to do with TOC, but we have have several setting options.

Please note that some Wikipedias have very restrictive policies about navboxes (eswiki doesn't allow more than three lines and those which don't offer more than categories), so the consumption argument wouldn't apply. For current mobile and app users this lack of information is not a minor bug.

The latest Iphone Wikipedia version 5.7.3 use the concept of 3D Touch and Peek quick actions that feels to be a perfect match for implementing navigation boxes and Authorization data..., were you have one start point and many destinations.....

For the user

  1. In the app Press hard --> a preview is shown
  2. When the preview is shown swipe the peek upward, the system shows the peek quick actions you’ve associated.... ==> could be the different alternatives for navigation ....

See developer.apple.com "Getting Started with 3D Touch"

I'm going to float an idea here to see about technical feasibility of a sketched idea (or maybe to spark a similar idea--maybe with Lua tables instead). (TheDJ's comments above are pretty cool idea too I think.)

Since we have available to us json pages on-wiki, would it be reasonable/possible to rework the template such that each page which is currently a navbox becomes a wrapper of a navbox and a separate json page, e.g.

{{navbox|Links-for-X-topic.json}}

Where template turns the json file into wikitext/HTML?.

Then, where mobileFrontend sees navbox, it goes looking for the json page and can do whatever it wants with them (could be something like DJ's comments above, could render/load a few in the same way as Related Articles... other ideas ~).

Hiding navboxes indeed brings inconvenience. For example, https://www.mediawiki.org/wiki/Extension:Cargo . Maybe we can use loadboxes, see https://minecraft.gamepedia.com/Template:LoadBox .

I can add some background on why they are hidden (tldr is that this is a trade off to better suit our users on 2g connections who we believe cannot even access our site without the use of an external proxy - a more pressing issue ):

  • navboxes table based layout are the least mobile friendly of all editor based content and would need a complete rewrite by editors to be mobile friendly (it does not lend itself nicely to responsive design). There is also currently no way to style content differently on mobile to desktop (a rfc has been open for 4 years now to drive that [1])

Well, at least this part is no longer relevant thanks to TemplateStyles.

  • they are html heavy (up to 10% on most of our larger articles) which adds to the bloat to our HTML which renders our site unusable to users on a 2g connection (reference list being the other contributor which is luckily in our control to fix). we need to make it possible for readers to load this separately.

Does anyone imagine a way to rewrite them to be OK in this regard?

Various people from all kinds of wikis keep asking me why aren't they shown on mobile :)

Just wanted to add: for dewiki (where navboxes have always been visible on mobile, but we certainly use them less frequently than enwiki does) I have created a responsive mobile version: examples. Should be live soon. Obviously this is just about the design, the problem of the heavy HTML remains.

Please also note that .navbox doesn’t necessarily mean a such complex and non-mobile-friendly table-based thing. For example, the authority control box at the bottom of https://hu.wikipedia.org/wiki/Barack_Obama is responsive and looks good on mobile as well (the boxes above it don’t, I know), but not even an !important rule can display it as long as it’s not present in MobileFrontend’s HTML output.

Well, but why does it use this class then in the first place? Navboxes on dewiki are visible because we never used the class, there is absolutely no need for it.

Because it builds on the same basic visual styles (colors, spacing etc., even the rule that collapses horizontal borders applies to table.navbox + table.navbox, not table.navbox + .whatever). If we used another class, we would need to duplicate all rules (quadruplicate in case of the border collapse rule: .navbox+.navbox, .navbox+.whatever, .whatever+.navbox, .whatever+.whatever). Actually last time I tried it with another template, not even navboxlike would work as all elements were deleted from the HTML source whose class attribute matched the .*navbox.* rule, even if it was not matched by the .navbox CSS selector…

Lovely. That’s the issue with mixing structural global semantics and local decoration (as already criticised in T262093) …