Hey, folks! I’m your friendly neighborhood Vanguard guy, Technobliterator, here to talk about how to make your Portable Infoboxes better.
The goal of Infoboxes is to convey summarized data on an article in a way that is easy for readers to consume and interpret. This may be four to five facts about the subject, but it can often include dozens of statistics and pieces of information. In instances where infoboxes are fairly long, it may be much more desirable to group parts of information together and organize it separately, to allow readers to more quickly search through it to find what they want.
When content should be split into groups[]
Whether an infobox is just a short list of facts, or a slightly longer list of data, it often becomes clear when data should be split in an infobox if it’s describing a different aspect of the subject. A wiki article describes multiple aspects about the subject, but a reader may only be looking up an article for one, or may not want to read both at once. Therefore, separating content into groups in infoboxes serves the same purpose as separating content under a different ==header== in articles.
On a gaming wiki, you would expect an article about a location to not only describe the gameplay information about what objectives or enemies you may encounter there, but also some lore information about its controlling faction, or where it is located on the map. It therefore makes sense to group background information under a “Background” header separately from information under a “Gameplay” header. Some information may precede both headers as it may fit either or both categories. Of course, if the list of enemies or the list of objectives here are much longer, it may also make sense to instead have separate groups of those, under an “Enemies” header and an “Objectives” header.
There are many other instances in which you may want to split information. On a movies wiki, you would expect an article for a character to describe their biographical backstory, as well as a description of them and any powers they may have. You may want to also group together behind-the-scenes information, such as their actor/actress, their character designer, and perhaps their first appearance in the series.
More complex management and naming group headers[]
While grouping content may be straight forward on some pages, on others it may be far more difficult. What happens when there are two very different sets of data describing the same aspects of the same subject? For instance, on a gaming wiki where a weapon has appeared in multiple games, or on a TV wiki discussing the same alien in multiple timelines. How should content be grouped then?
Let’s suppose the article is about a weapon called the “Axe of Doom” that appeared in Game 1 and Game 2. Let’s say an infobox for a weapon should list its ammunition, its power level, its cost, the location it was obtained and what quests it can be earned in. It may make sense at first for “Ammunition” and “Power level” to be grouped under an infobox header called “Stats”, while “Cost”, “Location” and “Quest” could be grouped under a header called “Obtaining”. However, all of these data fields will need to contain information for Axe of Doom in Game 1, and right below it, the data for its appearance in Game 2, if they are different. This does not make sense for readers, who are probably only looking for the information they want for the game they are playing right now. It therefore makes much more sense to feature two groups titled “Game 1” and “Game 2”, and group separate “Ammunition”, “Power level”, “Cost”, “Location” and “Quest” data fields for each. That way, a user only needs to read the data under the header of the game they are playing.
Meanwhile, if a TV wiki’s article is about an alien race called the Martians, which change in different timelines in the same series, the same rule may not be applied. If an infobox contains the data fields “Eye color”, “Skin color” and “Lifespan” which change between Timeline X and Timeline Y in the series, it may seem to make more sense to list it in separate groups for the timelines. That may be true, but what if both timelines are relevant to the series? What if the way the Martians have changed between the timelines is relevant to many episodes? In these instances, a reader would want the information to be grouped together. Of course, if the two timelines are totally unrelated, and Timeline Y refers to a full reboot of the series unrelated to the series in Timeline X, it may make sense to group them separately (assuming it doesn’t make sense to simply make two separate pages on the Martians for the different timelines).
Collapsible groups and grids[]
There are many other added benefits of grouping content separately beyond simply placing it under headers. Using the Axe of Doom example from our unnamed gaming wiki, we can explore how this wiki can make use of these features to benefit their reader.
Grouping content together allows the groups to be made collapsible, where content can be hidden or shown by default. This can be helpful in a variety of ways. Suppose the game series in which Axe of Doom is featured sees many more game releases. This may make its infobox fairly long, forcing users to scroll down to find the ammunition of the Axe of Doom in the newly released Game 5. Instead of doing this, since the information from a group for one game is only relevant to users playing that game (or wanting to learn about it for another reason), it may be better to make all of these groups for these games hidden by default, where users have to click to display it. This makes for much less time scrolling.
Grouping content together also allows content to be displayed differently from the typical vertical layouts. Using horizontal layouts, users can make content in a group into a grid of sorts. Let’s say Axe of Doom can level up with experience, and its power level and ammunition change based on its level. You may then want a group featuring a grid with the “Level”, “Power”, “Ammunition” in three fields and then the data for these below. This may fit perfectly fine an infobox without needing a table in the article. Grouping it and making use of the layout attribute allows infobox designers to do that.
But my data is too long and collapsibles aren’t helping?[]
While groups are a fantastic way to organize infoboxes, particularly larger than usual infoboxes, in ways that make them easier to consume for readers, they are not a panacea to all problems with large infoboxes. Sometimes, it may be better to organize data differently, such as including some information in a separate table (or a full width infobox) on the page rather than forcing it into several collapsible groups with horizontal layouts.