Most infoboxes summarize an article. By surfacing a few facts, they let readers quickly understand a subject.
However, particularly on gaming wikis, infoboxes can be much more data-oriented. Infoboxes on these communities are responsible for serving up actual statistics — and it makes them much larger. This kind of data-driven infobox may require you, as an admin, to adopt a different approach.
This blog will explain how to make your data-oriented infoboxes most useful for readers.
Make your data readable[]
Organization instantly improves your infoboxes. Group related statistics together, making sure that the most important statistics go first.
Let’s say you’re designing an infobox for a unit in Dungeons & Dragons. You should lay out the stats the same way the Monster Manual does. Not only will users be expecting that format, but the reason the authors of the Monster Manual chose that format is instructive.
They’ve put hit points, armor class, and speed together precisely because these stats will be the ones most often referenced by a D&D dungeon master. They will be used every turn. The stats used next most often are attributes (Strength, Dexterity, Constitution, etc) -- and so they go in the second position.
That doesn’t mean you need to slavishly copy everything from your game’s source. The Monster Manual lists actions next, but these are relatively infrequently used. So maybe you would choose not to put them in your infobox. Instead, your reader may be better served by a table in the body of the article which lists and describes each action.
The basic notion is clear:
- rank information according to importance
- keep related data together
- make sure the statistic you’re serving to your readers is significant enough to include in the infobox
Take advantage of group types[]
In Fandom’s infobox code, different group types have different layouts. Your readers will get more out of your infobox data if you choose to a group type that optimizes its display.
In some cases, you can stick with the typical layout with no modifications. However, if the stats you are displaying take up quite a bit of space, consider spacing these out both for desktop and mobile readers.
Going back to our D&D example: for the armor class, hit points, and speed, we want to give the fields appropriate width to make the data readable. Some types of data, such as armor ratings, are expressed in terms of both value and qualifier (e.g. "22 (Natural Armor)"). With the <format> tag, you can put these two separate pieces of data together on a single line so that it makes sense to your readers, while preserving them as distinct data points. Another common example of this is cost, where you can format a simple number (such as "150") so that it reads "150 gold". That keeps the word “gold” out of the variable called “cost”, allowing you to manipulate the variable as a pure number.
But this formatting typically requires a wider area for display. So make sure you choose a group type that accommodates what you’re trying to display.
Sometimes, of course, you won’t know exactly how much space your data will take. Some stats are just a single number, star rating, or even an icon. This is where smart groups can structure data to make the best use of the field's width. They reduce the height of the infobox and its individual parts, so they are perfectly designed for structuring data.
In our D&D example, putting the attributes in a smart group with two rows of three -- by using the code <group row-items=”3”> -- is the most logical way to go. Since attribute data is fairly compact and purely numerical -- things like 4 [15] -- smart groups are an obvious solution.
Multiple elements are better than one cluster[]
In some cases, infoboxes can become extremely long, at which point they will consist of several different groups with different pieces of relevant data. This can be frustrating for both mobile and desktop readers.
One of the most important things to remember is that you’re an editor. That means you have to make choices about what’s important to include, and what’s not. Infoboxes are meant to be summaries of the topic. So if your box is physically long on the page, it almost certainly is actually too long. As discussed earlier, more detailed information can (and should) be split off from the infobox and put into the body of the article.
An example of when infoboxes can get too long is if a page covers multiple entities, rather than a single entity. In this case, rather than stretching a single infobox to cover them all, it will make more sense for readers to instead separate them into different infoboxes for each entity. Place each below a different “===header===”, subdividing the different facets of that entity into groups and / or panels, making them most accessible and making a better use of the space.
Styling help[]
There are a few things to keep in mind when using stats infoboxes for readability. Icons are not a substitute for text labels. Icons are great, but they can’t convey information on their own. While it’s both popular and reasonable to use in-game icons in infoboxes, there’s no guarantee that the reader will immediately understand what that icon means. You’ll reach the widest possible audience by using the icon while also including a text name after or below the icon. Take advantage of collapsibles, but don’t overuse them. If not every group is helpful to every reader, include them in a collapsible element. This puts the reader in greater charge of the length of the infobox. For instance, if you’re making an infobox for a weapon that appears in multiple games, you may want to hide the stats so the reader only sees the ones they want. This is easy to do with infobox groups, as the function is built in. But be careful! You don’t want each collapsible element turning into a hidey-hole for a ton of data. If that starts to happen, it may be better to allow each game’s variant of a weapon to have its own infobox -- or even its own article.
Data hygiene and code readability[]
With data-oriented infoboxes, it’s important to keep your data (and code!) “clean”. Here are a few tips:
Keep lists in a single variable. Let’s imagine you’re you’re listing a bunch of items that are dropped by an enemy. Have only one variable called item -- i.e. -- and use an ordinary bulleted list to display all the items dropped by that mob. Don’t put each item on its own variable, like item1, item2, and item3. This applies if all list elements are equal. An exception is if the prominence is different. For example: if an entity is of different types, but one is primary, use a scheme like "| type =" and "| type/secondary =". When a simple list presents problems, consider asking for and learning how to use the Arrays extension.
Do not mix values of different types. If your data field contains two pieces of data which refer to different things, it’s better to use different parameters that affect the same <data> field. For example, if something costs 10 gold and 5 silver pieces, it may make more sense to give use different variables for each currency. That is, "gold=10" and "silver=5" is better than "cost=10 gold and 5 silver". The infobox can easily format the two parameters so that the reader can understand it. And you’ll be left with raw numeric data that you can play with elsewhere!
Use formatnum for numeric values. It’s actually better to give a data entry of 300000 than 300,000. But that doesn’t mean readability has to suffer. Just use {{formatnum:{{{value}}}}}, and value=300000 will still read as 300,000 in the infobox -- but you’ll be able to run the raw number through other functions without a problem!
The overarching goal is to make sure a parameter only takes a string of text, a numeric value, or another simple datatype (or a list of simple items of a single type). This makes things more readable, yet rigid enough to guarantee the correct values are entered.
More advanced boxes[]
For many data oriented infoboxes, data will need to be parsed, manipulated or just plain mangled! Other times, you will need to limit data to a few possible values. And on still other occasions, one stat will be the result of other stats.
In these cases, you can parse that data a lot better with parser functions, or even Lua functions, within <format> and <default> tags.
And if you find stats tricky, don’t worry. My friends and I on the Vanguard team will be happy to help!
Your thoughts[]
Do you have any stories to tell about making data-heavy infoboxes? If so, tell your tales in the comment section below!
