Tables and data structure

I don't like using tables in text documents. The problem with tables is that they’re dependent on presentation. If you look at the data being presented in a table in a format that can’t render the table the way it was designed, or on the limited display of a mobile device, the table data is often difficult to interpret, next to useless.

I started avoiding tables several years ago; at first, it was a logistical challenge to break a habit reinforced by others who still use tables in their writing. But I find the more I avoid tables, the more I relish the logical challenge of restructuring information into a new form that makes it even more useful. I’ve noticed several common data “mistakes” in tables that can be improved by taking data out of the table format and expressing it in some other way.

A list in disguise

Tables are sometimes used as a kind of horizontal list. There’s an illusion of comparison here, because the data on the x-axis is different in every cell, and each entry corresponds with the data on the y-axis. However, there’s often little relationship along the x-axis. It’s just a list of unrelated items, with each item’s corresponding data slotted in the column below.

Here’s a very simple example:

It’s deceptive. These things seem related. They’re familiar names from the Star Trek franchise, and at a glance the table appears to comparing the captains of different starships and space stations. However, the data isn’t actually being compared; it’s just three columns of three independent facts, placed adjacent to each other. The name of the captain of one ship has no effect on the name of the captain of another. No external factor binds these facts together. The data is only being presented as a table for convenience. Here’s the same data, restructured as a list:

• Enterprise: Picard
• Voyager: Janeway
• DS9: Sisko

Mystery of repetition

Tables can be cumbersome, because the table format insists that cells are populated. Attributes can’t be taken for granted, because the lack of data in a cell suggests a notable absence, even when the absence of data might be a positive trait. Merging cells can sometimes reduce repetition. For example, when two columns share one trait, a long cell extending through two columns can combine the data into one:

However, the matrix of data isn’t always so simple. Sometimes neighbouring columns that conveniently share one attribute suddenly deviate and share an attribute with a column on the opposite end of the table.

Written as a list, you can imagine (depending on context) that some data might be omitted. Instead of listing every trait explicitly, you can include only data that’s exceptional:

• Unix-based systems
  • Linux (open source)
  • Mac (replaces most Control shortcuts with Command)
• NT-based system
  • Windows

The same data, restructured as a list, is easier to read.

This becomes even more significant when most data in a table is redundant.

In a longer document, this table of repeated information can essentially be replaced by a footnote that explains that only the Sunlight unit uses an Intel CPU, while others use AMD.

Maintain readability

Despite their drawbacks, I acknowledge that some tables really are better off as tables. Sometimes a table is dense with unique data that benefits from an evenly-spaced grid, such as this:

You might reasonably hesitate to convert that table to a list. Unless you can guarantee that the table is rendered exactly as intended, much of the data it contains could become difficult to reference through separate lists. I’ve used a somewhat simple table for this example, for fear that it wouldn’t render well on a website if there were too many cells on the x-axis. The longer the table gets horizontally, the more difficult it is to parse. There’s a good reason few people do heavy spreadsheet work on a mobile screen.

Even for this arguably reasonable table, I would likely attempt to rewrite it as a list by providing reasonable context before the information. Assuming the table is for a game where the reader understands the meaning of the column headings, I might write:

This table shows which colour in the game is associated with each domain and faction.

• White (W), Max 9: Protection, Paladin
• Blue (B), Max 8: Control, Wizard
• Black (K), Max 6: Sacrifice, Necromancer
• Red (R), Max 8: Aggression, Berserker
• Green (G), Max 10: Creation, Druid

Depending on what players of this imaginary game needs the data for, the list could be restructured, but in this text format the data is preserved and easy to access regardless of layout.

No table and no list

Sometimes a table is purely gratuitous, a layout convention that a writer uses because it’s a valid way to convey data. It isn’t always necessary, though. Sometimes everything you’re trying to say in a table can be said in a sentence.

Here’s an example sentence summarizing one of the tables from this article:

ACME Industry widgets have 8 MB of data with a text-based interface. All use AMD chips, with the exception of the Intel-based Sunlight model.

It’s short, direct, and it explains several different data as a single monolithic item, with just one exception.

Simplify your markup

I’ve yet to experience a markup language that can gracefully express tables in a syntax that’s both easy to read and easy to edit.

I often write using Markdown. Markdown-style tables are nice to look at, but drawing ASCII art tables creates awkward page layout. Some particularly pleasant text editors have plugins to help manage ASCII art tables. For example, when I create a table, I often use Emacs - but that’s a consolation rather than a solution.

HTML and Docbook can only express a table verbosely and without any sense of its ultimate visual layout. It’s hard to read, and difficult to edit without confusing the tags or losing track of which cell aligns with which other cells.

That why in my writing, not creating tables is often the best solution, rather than dealing with tables in a source document.

Re-imagine your data

There’s a time and a place for tables, but I find it is an exception to the rule of good lists and well-written, descriptive sentences. Restructuring data you might have otherwise placed into a table and instead writing it as a list allows you to visualize your data in a new way. Abolishing the strict table structure can help you make connections between data in ways you weren’t even looking for.

You may not ban tables entirely from your writing, but the next time you create one, you might pause to challenge yourself to restructure your data in an interesting and satisfying way. The exercise is a good one, and you just might surprise yourself in how well data can be displayed without tables.