Hydraguy the Builder

Building tables is both a science and a craft. It can be a fun challenge to present data!

There are several ways in which Fandom communities craft their articles. Some are focused on encyclopedic-like descriptions, while others are oriented towards fanon, role-play, or other discussion. The vast majority document a specific game, television show, animanga, or films. When presenting documentary articles, sometimes narrative text and images stand alongside data tables. Presenting data can be a challenge to avoid overloading a reader's attention while informing with the most clarity.

An important part of presenting data in articles also involves imagining if that data were not there, adding clarity to the text. Like images, data should enhance the article itself. If the article is not sufficient length without adding fact tables and figures, you should consider how much "meat" you are attempting to add spice to.


In particular, game data and episode information is placed in tables. Search engines particularly like data structured into tables, and they are generally easy to understand with clear headings. Table formats used on more than a few pages should ideally be intuitive enough to not need a legend (Example: Character names with an asterisk * are deceased.). Tables that are inside sections (in other words, under section headings) should have at least a sentence (if not a paragraph) explaining the topic of a section, in addition to any tables. We talked a bit about tables in a previous post, and would like to add to that conversation in this context.

Data Hierarchy

Presenting data in articles should be intuitive for users, and visually appealing.

Tables (where they are placed) should always come after the page's main narrative, as the ideas described should justify and set up understanding of what is in the table. Collapsible tables that are initially loaded onto a page in a collapsed state are considered less significant by by search engines, and they are initially skipped by human eyes as irrelevant information. Therefore, the general article should be well understood as if the table was not on the page at all in terms of the information a collapsed table provides. With the narrative being the most important focus, this provides further reason to place any table after the related narrative.

Tables are preferred to lists in some circumstances for readers. When lists have multiple hierarchies and nuances, reformatting the information into tables can present more readability. At the point that each list entry has a note to clarify its relationship to the whole, especially where those notes are consistent in the text (or information icon) provided, a table becomes the ideal solution.

Appearances list example - DC

This is an example of the type of hierarchal list with annotation that is best reconfigured and displayed as a table.

Tables should also be sortable, wherever they can be. Colored cell backgrounds, for accessibility reasons, should not be the only indications of information and should be used to emphasize text. On Fandom's current mobile skin, only the first 4 columns are shown without scrolling. This puts a special imperative that only tightly related information be shown about given items. In practice, it is good to separate some facets of information about the same items, and can create more informative content in separate pages rather than having many columns in the same table. It may be worthwhile to explore putting tables such as these on separate pages and distributing the information. At the same time, tables with few columns do not always present well on desktop; data tables longer than a page height should be examined at 70% or higher page width for ideal aesthetics. If you're unsure what the best way to present table information is, your Wiki Manager is usually a great resource to ask!

Tables absolutely should not be used to create page layouts or individual element layouts. Do not use them to make notices, quotes, hatnotes... especially do not use them to construct the entirety or majority of your pages! Web designers have been instructing us to avoid this for 20 years, and there is really no excuse to do this in the modern era. Tables should be used, whenever possible, only for producing spreadsheet-like demonstrations of data.


An example of real life informatics, with an intuitive design that requires little explanation and no legend.


Infoboxes are a very standard part of wiki pages, in particular. They are intended to provide highlights and essential data to compliment what is in the article. Fandom has many communities where the infoboxes are longer than the body of the article being described, because there is simply too much information being presented. We fully intend to discuss the best practices for designing infoboxes in a later post, but while we're discussing data we would be remiss not to mention them in this context. As a rule of thumb, only add the information that is most critical to understanding a character. If the infobox is more than 5 times as tall as it is wide (especially on short to medium sized articles), efforts should be made to reduce the overall height; an infobox should never exceed two "page heights" in length. That may include setting a maximum height of some data points (and scrolling those rows) via CSS, or setting one or more groups to be collapsible.

Graphs and Interactivity

Graphs can be a great way to show data effectively. Unfortunately, there are few solutions available to Fandom users at present that can use graphs to their best advantage. To generate graphs from data, some interactive JavaScript needs to be able to access data on a page and then draw it using the viewer's browser, which can significantly add to the resources needed to display on a page. It's also worth noting that graphs shown on mobile tend to take up valuable space and be too detailed to see all aspects clearly. We intend to talk more about JavaScript in an upcoming post, but the general rule is that it should be used only to embellish what is on a page, rather than create more for the page.

We have discussed tabs before as well, in terms of interactivity. Placing tabbed areas inside sections, particularly for large volumes of information (text, galleries, or tables) should strongly be avoided, as this hides crucial information from your readers. If the information is too large for comfort, and you are tempted to place it under tabs, please consider splitting it into its own page using the methods previously suggested.

Placing audio file links at the top of articles or sections tends to be confusing in an era where video is commonly embedded into articles; in the cases where video is already in an article, this presents a more difficult to understand and control user experience. In the cases where short audio clips are consistent for a page type (a monster's roar in a game) and strongly associated with the topic at hand, these make for much better infobox data items. Where they are quotes, they should also be provided with a text transcription and not be placed in the lede (as should other quotes not be). However, our internal data does not show that embedded audio files are played often.



Notices intended for readers to clarify article status (such as spoilers) should be limited in both number and intrusion. Many notices are graphically ornate, which can be very invasive in proportion to the "above the fold" space available. These should not be used to convey crucial data, and again, should only be used to embellish the understanding of the article itself.


We mentioned in an earlier post that quotes should not be placed in the ledes of articles, and as they're presenting another form of data (one cloaked in narrative), it's a good place to talk about why. If it's a quote of sufficient length, you also get banner blindness, causing readers to overlook what you're trying to say.

It's also potentially misleading. Take DC Database's Batman article for example: it starts off with a quote by Superman about Batman. This confuses both readers and search engines alike when they're trying to understand what they're reading.

To be honest, it's an awkward journalism / documentary issue. There are some basic writing complications at play. Some great books start off chapters with quotes or excerpted dialogue that add context or tone to a chapter's contents. That's not same as an encylopedic style, or a wiki-pedic style, or a scholarly writing style (such as APA), or a news article. In fact, many style guides for journalistic articles warn against quotes at the beginning. and are two public resources that illustrate the reasoning why. This is one example:

The most important reason for not starting a story with a quote is that a quote itself seldom shows the news value of your story. It is your task as a journalist to tell the reader what is news. You should tell them what is new, unusual, interesting or significant about the information you present. Only when you have told them what is news should you use a quote to support your intro.

A standard intro in reported speech is the most effective method of expressing an idea. Very few people speak well enough to say in one sentence what a good journalist can compress into a well-written intro.

Starting a news story with a quote produces awkward punctuation. By putting words inside quotation marks, you give readers an extra obstacle to overcome just at the time when you are trying to grab their attention.

Beginning with a quote also means that your readers see the quote before they know who has said it. How can they judge the importance of the quote without knowing the speaker?

When it comes to writing articles, things we learn from older media forms are still relevant. The best resources to tell us how and why to do something may come from unexpected places.

Narrative is king

While tables and templates make for enticing additions to narrative, they should never replace narrative. Pages and sections that consist only of tables are doing your readers a disservice. Additionally (and not coincidentally), these do not parse well among search engines and make pertinent information hard to find and to understand. Narrative is always important and key to conveying knowledge.

Just as a news article about the results of a sports game would never provide only a table showing the plays in the game — leading the reader to draw their own conclusions about what happened — no article should be without narrative to explain and place in context the topic of the article. Wikis are, simply put, not meant to be databases.

Building out pages with the best views of data is an important way to inform your readers. It's not always easy, but the reward of having happy users is a strong overall community. Your Wiki Managers and our Staff are always available to give you the help that you need!


Isaac Fischer Fandom Staff

Isaac rose from the ranks of Fandom contributors to join the Community Technical team in late 2015. He is now an Editor Experience Specialist, with a focus on User Education. Isaac is a television and book fanatic, a sucker for the great outdoors, and a lifelong learner. He's been coding since before attending school but didn't discover Fandom until 2010. Even now, he's hard-pressed to identify his favorite fandoms.
Want to stay up to date on the latest feature releases and news from Fandom?
Click here to follow the Fandom staff blog.

Interested in learning more about community management on Fandom?
Click here to view our community management blog.

Would you like insights on wiki building and usability?
Read through our Best Practices guides for keeping your community growing and healthy.

Want to get real-time access to fellow editors and staff?
Join our Official Discord server for registered editors!

Community content is available under CC-BY-SA unless otherwise noted.