Page MenuHomePhabricator

Show Navbox templates in mobile skins
Open, LowPublic


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.

The bottom of the mobile article "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 has a "Theatres in London" navigation box (shown in a 'collapsed' state by default).

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


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
TheDJ added a comment.EditedJan 21 2016, 4:56 PM

A Category is a 'topical grouping' relation between otherwise not necessarily related articles. They could also be shown from such a subpage and browsed etc. They are easier to provide alternative interfaces for, since they already are tracked as proper metadata. After having the above in place, they could probably be used to explore 'alternate UI' for browsing relationships (Who says we need to use the exact category page design on mobile?) and can be used as a staging and experimentation ground for UIs of 'other' Wikidata relations.

TheDJ added a comment.Jan 21 2016, 5:02 PM

Sequences of relations might lend itself to be represented in carousel like interfaces on small screen form factors ?

Yanpas added a subscriber: Yanpas.Feb 26 2016, 2:27 PM

I would also challenge the implicit assumption that the automatically generated "Related Articles" suggestions are always inferior to the navbox links. Among the problems with navboxes that many editors (including myself) have pointed out for many years is that they indiscriminately link among all articles declared to be in scope of the box. (The German Wikipedia, for example, has a policy that forbids many of the navboxes that are prevalent on the English Wikipeda.) The "Related Articles" selection, while automated, has the advantage of being able to take the specifics of the article into account.

E.g. for [[en:Cow Palace]], the three Related Articles links currently seen at the bottom of are vastly more relevant and useful than 90% of the (more than 200!) navbox links at the bottom of the desktop version:

TheDJ added a comment.Apr 18 2016, 2:40 PM

@Tbayer I do wonder what you think of my "Idea for suboptimal but better than nothing next step: T124168#1952372 does not show the "Court membership" section in the infobox due to .navbox being indiscriminately stripped by MobileFrontend. is the relevant template.

Nemo_bis updated the task description. (Show Details)
MaxSem removed a subscriber: MaxSem.Dec 19 2016, 12:58 AM
Nirzar added a subscriber: Nirzar.
ovasileva triaged this task as Low priority.Dec 20 2016, 11:45 PM
Jdlrobson moved this task from Backlog to Later on the Readers-Web-Backlog (Tracking) board.
Izno added a subscriber: Izno.Jul 7 2017, 5:07 PM
Jdlrobson moved this task from Needs triage to Triaged on the Mobile board.Jul 25 2017, 5:51 PM
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.
Ahecht added a subscriber: Ahecht.Jul 31 2017, 8:54 PM
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) 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.

Jdlrobson updated the task description. (Show Details)Oct 27 2017, 12:52 PM
Jdlrobson updated the task description. (Show Details)Oct 27 2017, 12:56 PM

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:

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

D1gggg added a subscriber: D1gggg.Nov 1 2017, 4:10 PM
D1gggg added a comment.Nov 1 2017, 4:18 PM

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

D1gggg added a comment.Nov 1 2017, 4:24 PM

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:

D1gggg added a comment.EditedNov 2 2017, 11:27 AM

Possible version without nested navboxes:

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

<s>I'm stuck with "alignAsides" 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*.

D1gggg added a comment.Nov 3 2017, 1:02 PM

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.

-jem- added a subscriber: -jem-.Nov 28 2017, 10:05 AM

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 "Getting Started with 3D Touch"

Izno added a comment.Feb 23 2018, 9:05 PM

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.


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

Dvorapa added a subscriber: Dvorapa.Jul 3 2018, 3:13 PM
Jdlrobson updated the task description. (Show Details)Jul 6 2018, 9:08 PM
Jdlrobson updated the task description. (Show Details)
Jdlrobson added a subscriber: Deskana.

Hiding navboxes indeed brings inconvenience. For example, . Maybe we can use loadboxes, see .