User blog:Kjnoren/A Reconsideration of the Navbox as a Portable and Modular Infobox, or the Navinfobox Blog

Practical navigation is not a fully solved problem yet on wikis, and likely never will be. It is also a hugely important topic, as evidenced by that no less than three out of the ten Best Practices blog posts directly concerned navigation in various forms: The best possible local navigation bar, Categories and Navigation on Fandom, and Organized spaces on Fandom. It was also discussed in the Main Pages on Fandom blog.

Linking solutions
Note that all of these solutions can be used independently of each other and complement each other.

Inline links
Inline links, that is, links that appear in the running text of the page, are arguably the most important links, and are probably also the most numerous. Their greatest value is that the link appears just as a topic comes up in the narration or as a character is introduced. They can also carry semantic value, as the link hopefully appears in a context which explains why the link is there or what the relation between the linking page and the linked page is.

But they are not perfect. If every instance of a topic on the page is linked, the reader will likely experience link fatigue, and maintaining the site becomes harder. If only the first instance of a topic is linked, the reader can be left hunting for the first appearance of the topic, which would carry the link.

Navboxes
Navboxes have been used on wikis for a long time. Their advantage is that they will provide a predictable place for links, so a reader will know where to look for the links. But navboxes also have drawbacks. They provide less information on the link semantics—why is there a link to the topic? But the usability troubles are arguably much worse. Navboxes tend to place several links in close proximity to each other, making it hard for the eye to pick out each individual link. It more often appears as a big blob rather than something that can be easily scanned.



Since the navbox tends to become large and visually overwhelming, it became popular to place it out of the way—on the bottom of the page—, to make it collapsible, or both. But both those solutions lessened the benefit of providing links in a predictable and easily-accessible location. The usability issues on mobile are so severe that both Fandom.com and Wikipedia simply omit the navboxes there.

Navigation bar
The navigation bar can be viewed as a variant of a collapsible navbox. Like the navbox it provides links in a predictable manner and position, and it is also readily available no matter which page the reader is on. Since it provides a fixed set of navigation links per-wiki the reader can learn how it is structured, but it also means that it is not easily possible for it to provide links unique to the page the reader is on.

My understanding is that the navbar is more popular amongst editors than it is amongst casual readers, but this is second-hand information. It however fits with the need to explore and learn the navbar.

Lists
Lists of links are a very popular tool, and has been with us since before there was a World Wide Web. They can appear inline on a page or on a separate page. They can be a natural way to present the appearance of characters in a story or the locations in a game. One benefit of lists is that they can be ordered and annotated and not simply sorted. The characters in an episode can be shown not alphabetically but in the order they appear in, and characters without enough information to have their own page can receive an annotation of their role (like “Joe, a city guard”). Locations can be grouped so places in different cities appears under those cities, and not simply in a flat list.

Categories
Categories are also sometimes used as navigation aids. One apparent benefit of them is that the fandomdesktop skin shows them prominently on top of the page, but I’d argue that this benefit is a mirage. The list of categories is essentially unsorted, and shows at most four items. It also links to groups of pages rather than a single page, leaving the relation between the page the reader is on and the other individual pages nebulous.



On the category page, the links are essentially unorganised. They are sorted alphabetically, but there is no way to provide a different order, provide greater structure, or annotate the links.

Wikipedia has an extensive guideline and discussion on categories, lists, and navboxes, with plentiful examples: Categories, lists, and navigation templates. It also goes much more in-depth than I do here.

The infobox
Most of us may not think of the infobox as a navigational aid—at least I certainly did not—but many infoboxes are rich providers of links. A character page can provide links to family members, places of residence, groups, events, or appearances. Since the links appear with a headline or label they get some context, and the default infobox provides more space for each link to breathe compared to the default navbox.

The blog post on infoboxes recommend using it as a navbox, but the problem is that the default mechanism to do so is… not great. The  element has the issue that it is fixed to the infobox, and not tailored to the page it appears on. It also appears in both larger text and in bold compared to the rest of the infobox, overwhelming it. It is a poorly designed navbox that is shoehorned into an infobox. I think these limitations are apparent in that I have found very few uses of it in the infoboxes I’ve looked at while doing research for this blog.

Cognition and ergonomics
I have recently read some articles and research on human cognition and design, and while it was rather basic I received some new understandings and renewed my appreciation for some old ones.

One is that whitespace matters for scanning and searching. Another is that the more elements there are, the harder it is to discern each individual element. Our job as editors is not to necessarily present all the links, but to present those that are the most valuable, pertinent, and important for the reader at the given moment. Just as we should curate what goes into the opening sentences of a page or which facts go into the infobox, we need to curate the links, especially those that appear in prominent locations.

Plentiful whitespace between links does not only help to recognise each one, but also makes it easier to hit the right link. This is especially relevant for mobile use.

Infobox + Pagelists = Navinfobox
I set out to try to combine some of the elements of the navbox with the infobox in a less intrusive and more flexible manner. I call the basic building block I arrived at the pagelist. The pagelist can be viewed as an extremely simplistic navbox or navbox fragment. It is literally just a list with links. But that makes it easy to maintain and to integrate into other pages in various ways. The simplicity makes it easy to style using CSS, but it also makes it possible to make custom one-off pagelists directly on a page, if there is a need for a custom set of links. It is also possible to add structure to the list by nesting it.

Conceptually the pagelist differs from categories and regular lists of pages in that there is no expectation that it will provide a full set of pages regarding a concept or set of objects—only that it will provide the most important ones for a specific case. Unlike regular list pages it is also not intended to be visited as-is by readers, and thus they live in the Template namespace.

Creating and maintaining the pagelists requires discipline, and I set an upper limit of about seven or eight objects in them for myself. Any more than that, and some other objects would have to be removed from the list or moved to a new pagelist. Preferably the number of items would stay around five. I also decided to limit the number of pagelists that can be added to an infobox. Infoboxes with other information listed could receive a maximum of two pagelists, and infoboxes of nothing but pagelists—I dubbed that a conceptbox—could receive three. That would hopefully keep the amount of presented links to a manageable level for readers.

As I integrated the pagelists into infoboxes I noticed some patterns. One was that in some cases there were already labelled links present in the infobox. In those cases I chose to not remove the labelled entries from the individual infoboxes, but to remove the link from the pagelist. Editorial judgment is needed here.

The finished navinfoboxes
The resulting navinfobox is readily usable without any styling, but I set out to style it rather heavily, as is my wont.

The navinfobox with nothing but pagelists is rather similar to what Wikipedia calls a sidebar. I called this a conceptbox, but that was mostly a name that came to mind as I first started to explore this.

Implementation was relatively straightforward. The pagelists are collected in their own category for ease of maintenance: Category:Pagelist_templates. The conceptbox is rather simple and was easily created. The standard infoboxes proved the trickiest. The pagelists are inserted into the infobox as a group, allowing custom styling. The CSS can be found in  and   as usual, hopefully usefully commented for readers.

The individual elements are there, but the examples above are not yet finished. Apart from the bug in the mobile skin, I am not yet fully happy with the presentation of the navigation element with “All appearances”. It can be argued that there is a loss of semantic meaning with the shift from the fields “next” and “previous” in a book series to have the entire book series on hand. Perhaps that can be solved by using an ordered list instead of an unordered for use by search engines and other text parsers? But the basic elements are all present.

Addendum
See Navinfoboxes on the Portability wiki for skeleton implementations, including CSS, of conceptboxes and navinfoboxes.

Final thoughts
The big difference between the navinfobox—and the conceptbox—compared to standard navboxes and Wikipedia sidebars is that the navinfobox is meant to be constructed or adapted to the page it appears in on the fly. This is allowed by keeping the syntax of the pagelists very simple, by the flexibility of the portable infoboxes, and the decision to centralise styling through CSS files.

It is also explicitly not meant to replace or supplant other navigation systems. Its goal is rather to provide a limited set of links, in a readily understandable form, that are highly relevant to the specific context.

And finally apologies to Diana Gallagher, whose song title I riffed.