Where have all the tables gone? Not that I miss them — I was never the biggest fan of tables — but there sure seem to be fewer of them about than there used to be.
Tables have been a staple of tech comm for a while now. Engineering documents have been full of them for many years, and Information Mapping encouraged their widespread use on the grounds that they stood out and made it easier for readers to find information in a sea of grey text.
I’ve never quite understood this point — if you are going to employ a device that encourages readers to skip the grey text and go straight to the table, why bother to include the grey text at all? But whatever: tables were hot. Now, it seems, they are cooling off rapidly.
Take this blog for instance. I have been writing it for about a year now, and It contains no tables. In fact, for the longest time I didn’t even realize that WordPress’s default editor does not even support tables. And on reflection, I can’t remember any blog I’ve read that had a table in it.
Desktop publishing probably played a part in the rise of the table. Specifying a table in a typescript, and dealing with how it would finally be laid out and how well it would fit when eventually be set in type, was a difficult proposition. You could do it, but you would not do it lightly.
In a desktop publishing program, though, tables are easy-peasy. You can create one with the click of the mouse and slide the tables and cells around to make everything fit. It was a table free for all, and suddenly tables were popping up everywhere; sometimes multiple tables per page. It tablepalloza in the tech comm world.
But things are now going in the other direction. The heyday of the table is over and they are in decline. Their seem to be three principle causes of decline: the Web, structured writing, and mobile.
The first problem for tables on the Web is that the Web provides a variable-sized page. When you created a table in a DTP application, it was usually intended for display on a page of a fixed known size with fixed known margins, and you could hand fit the table to the page and make everything look right, right down to touching up the character spacing in a particular field to avoid a bad wrap.
On a Web page, however, the author does not control the page size, or the text size, and cannot even rely on the font being available on the reader’s machine. Even if you attempted to specify the exact size of everything in pixels, you still could not be sure the table would render as desired, and pages specified in pixels could become unreadable as people moved to higher resolution monitors.
Structured writing is no friend of the table either. To be sure, in the early days of structured writing, when it was still aimed principally at paper production, there was the CALS Table Model, which was certainly comprehensive, but which could give you the cold sweats if you had to use it or process it. WYSIWYG SGML and XML editors helped, but you still had the same problem you have with HTML: the whole point of structured writing is that you don’t know what size of paper or glass the content will be rendered on, so you don’t know if your table is going to fit.
A more versatile solution for structured writing applications is to write reference material using either a generic reference schema, or, better, a schema written specifically to capture and structure the information in a more semantically rich way. The virtue of this approach is that not only can you render it differently for different media but that you can also use the data to drive a look-up form or widgets. And once the reference data is captured in a non-tabular format, it is usually easier to render it in a non-tabular format as well.
And now we have mobile. That means small screens, lots of scrolling, and manipulations with stubby fingers. Interactive elements like look-ups and schedules, are increasingly moving to apps in order to maximize usability on the small screen. A table is pretty much a disaster on a phone screen. You can’t see all of it at once, you have to scroll both horizontally and vertically to view it all, and if you are doing a two-value look-up, you can’t keep both key values on the screen at once. Hoards of apps and widgets are again displacing the table from all but the most barren ground. (Metaphor: barren ground = paper.)
Here’s my question then: is it time to drop tables from our schemas, and from our authoring practice generally? Interactive media do look-ups better, and the every growing diversity of screen size, resolution, and media means that there is just no way to be sure tables will look right or be usable. Tables as a presentation option when outputting to a media we know supports them well might still be appropriate sometimes, but they should be created from a structured reference source that can be used equally well to drive an app or a widget.
Time to go cold turkey on writing tables?