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.
But the Web had more bad news for tables than simple layout problems. Things like schedules and value lookups, long the domain of tables in the paper world, were quickly moved to interactive forms and JavaScript applets that let the user choose keys from drop down lists or plug values into fields and have the machine do the look-up and display the result. The web is full of reference material, and almost none of it is in tables. Widgets and forms rule now where once peaceful tables grazed.
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?
Another factor: tables are a pain in wiki markup, even more than in structured authoring, where a wysioo editor can make things easier. Some wikis now offer a wysiwyg editor, but editing in a browser is still difficult.
In any case, tables still have a place in the presentation of information. As with many other things, how frequently they’re needed depends on the domain.
I wonder when the table was invented. I read once that the (ancient) Romans had no notion of a table for presenting information.
Hi David. Thanks for the comment. You raise an interesting question, and one that is not easily Googleable. I wonder if Arabic numerals with their idea of place would have contributed. Certainly by the time that the double-entry bookkeeping was introduced in the 14th century, tables must have been in use.
I agree that tables still have a place in the presentation of information. My question is, should they still have a place in the authoring of information, or should we author in more abstract formats and selectively present that data in tables or in other devices depending on the presentation media.
Hi Mark,
Nice article. Loved the pro writing with the easy-peasy mixed in there!!!
I think it depends on the audience. For technical audiences, the answer can still be yes. My personal theory is that technical audiences are often evaluating material, versus reading it for educational purposes. Often, they are coming in with their own set of technical assumptions and hypotheses and so on. So, I always want to give them some easy ways to cruise through materials and basically, check it off in their heads if it does meet their assumptions (so they can quickly cruise through and say, yep, boring, okay, knew that, yep, yep, yep — the famous table), and then if they see something they weren’t expecting to see (as in, wait, that thing has a tolerance of .05″, are you serious, that’s just not going to work, no wonder), give them an easy way to find the goods on that one piece. Meantime, for an audience that is reading for information and education, I agree with you. Tables can be good summaries, and maybe even good launch pads – like sprinkling mini-TOCs throughout a highly technical doc for do-it-yourself navigation within sections. LOL – a lot of engineers I know are big time do-it-your-self-ers! And yet, I agree. I did info-mapping in the past. Done well, it’s pretty nice. But done just to do it (as in, all-hail info-mapping!!!) – eeeooouuuuu, you just get poor results in a fussy format! For most of us (and we are all now technical audiences, of course, even if not engineers), tables can be nice if a brochure-type cruise through the material makes sense right there. But for engineers reading something that’s actually in their own field of expertise, so they’re just cruising through — like okay this thing is nice, this thing is lame, what seems to be the deal with this piece of technology and where can I build on it or improve it or suggest this part of it go in the rotating file — tables are still good. I asked the engineers. They liked it. I tried to write a few connective sentences, and they were like, eh. They didn’t need them! So I took them out! Does this work for you guys? Yep. Okay — my job is to help you get something that works for you, ya know? Whatta concept! Tables and graphics worked, so I designed the doc like a long brochure with all the specs on really cool tech toys, very few words. They really liked it and assured me that worked great for them.
What say you on this comment, Mark? Like your article and very glad I found your site! Easy-peasy – LOL – luv that. – Maura
Thanks for the comment Maura. You raise an interesting point: the table not as lookup device but as a kind of summary or maybe even infographic. Perhaps we need to codify the different things for which tables are used and consider their appropriateness and implementation separately.
While lookups can be useful, that assumes one knows the right keywords to call up the answer, or that one wants a specific answer in the first place. I think there’s still a need for human-browsable tables, where one can scan the full dataset by eye. Consider the student wanting to refresh his memory on a set of information right before a test, for example, or someone to whom the content is unfamiliar and who is therefore unsure what to search on. I don’t know that data needs to be encoded as a table, but the ability to display it so, I think is still highly useful. Nothing can present as much information in such a compact format so well.
Hi Michele. Thanks for the comment. I think your point is similar to Maura’s — the table is sometimes a summary rather than a lookup. The interesting thing about the case you raise, that of a student reviewing information before a test, is that the student is probably the person most likely to be doing that review using a phone interface on which a table will simply not fit.
I think it is reasonable to say that nothing can present as much information statically in such a compact format so well, but the raising importance of mobile devices makes me wonder if we should be looking for a dynamic format for presenting this type of information in environments where a table will not fit legibly on a screen.
Mark,
I think tables still have their place, but it depends on the contents, the context and the medium, as you said, and the audience. (I think you said that, too.)
Still useful at times, IMHO, in documents (gasp – yes, the document is not completely dead!)
Cold Turkey on tables would only be an option if you are going Cold Turkey on documents, it seems. *Unless* you could create a doc output transform from your XML-based system that could create page-friendly displays from you assembly of page-one-ready topics… is such a thing possible? If yes, at what cost? For those of us with customers who still want docs, it’s not feasible to abandon the form that makes information digestible on the page (PDF).
Frank and Melanie, thanks for your comments. I take it that by “document” you both mean paper document. If so, I agree that tables remain a valuable presentation tool for paper documents. What I am thinking about is exactly what Frank describes: ceasing to author tables as tables, but creating tabular data as tabular data sets that could be published as tables on paper and in some interactive form in other media. This approach is certainly possible: database reporting systems translate tabular data into printed tables all the time. The question of how much it would cost, on the other hand, depends greatly on what kind of authoring tools or system you are using. This might actually be easier with some older authoring tools like Word, that feature a mail merge option, than in something like DITA or a WIKI where such featured may not exist natively, though you might be able to implement them.
I guess maybe the larger point here is whether authoring systems and tools can or should start to include this kind of functionality — whether they should begin to focus more on data representation and manipulation rather than just on publishing.
Mark,
The darn shame is that visual information, in a world that wants to reformat everything, simultaneously, to fit on a postage stamp sized handheld device and a 24″ monitor, has been left by the wayside. And while everything may be miscellaneous, some things, still, are also not.
We need to attribute some information and when we have a pile of things with a collection of similar attributes, it can be very useful to represent that information visually. By this I mean, put them in a table so that the attributes don’t need to be named constantly, but so that they jump into our brains because of their physical position. Adjacency matters, and not only horizontally but vertically as well.
This is what a table of contents is about – vertical adjacency. I know all about EPPO. But I also know that tagging is still alive and well, and that instead of reading all those little tags as words or icons, it’s just plain convenient to represent a tag by positioning the information that owns it physically on what we still call “a page.” Our brains are so well-suited to understanding the meaning of visual adjacency, that indentation, font and font-size are effective means for breaking it. Imagine simply dismissing that marvelous ability?
Finally, consider a relational database, which can be, of course, a veritable mountain o’ tagged information. We still need databases because no matter the marvelous and ineluctable dynamism of emergent structures, there comes a point when some things really do have similarities, and those similarities can be incredibly useful in a brain that seeks, devises – desires – and is so good at using patterns.
So, in answer to your question, “Is it time to go cold turkey on tables?”, I say it will never, ever be that time. We just need technology to catch back up so we don’t have to constantly squint into those damn little screens anymore.
🙂
Thanks for the comment Tim. It does indeed seem ironic that we have gone so quickly from the extreme of saying everything has to be visual to the extreme of saying that everything has to be textual, because only text fits comfortably on a phone screen.
Personally, I am among those unconvinced that everything has to be made readable on a phone. I use multiple devises, but I find I almost always hate it when I browse on my phone and am presented with the mobile version of a site rather than the full site. A perfect example of this was when I was trying to get information on the Avis car return location at Calgary airport. There is lots of useful information on the location and hours on the Avis website, as a Google search made clear. But as soon as I chose the link to the return information, avis.com detected I was on a phone and redirected me to their mobile site, which is just an interface for booking a rental. The mobile versions of most other websites are frustrating and unsatisfactory in one way or another.
My view is, I own several devices. If I want a small piece of information from your site, I can find it on your regular site using my phone browser. If I want a lot of information from your site, I won’t try to read it on my phone anyway — I will switch to a different device. I’m not at all sure that I am typical in this, however. It may be, as it is often suggested, that many people are becoming phone-only information consumers.
As to how much adjacency matters in the display of information, I think it is a really interesting point, but I wonder whether it is a learned mechanism based on working on paper or an evolved mechanism based on our general spacial sense. If the former, it may not exist in the next generation. If the latter, micro-screen media may have to find creative ways to accommodate it. I’m not sure that scrolling around a static table is going to be one of those creative ways, however.
I heartily disagree. Tables are my bread and butter this year: I’ve been writing hard core reference material (where angels fear to tread). It’s pure guts.
Hi Tina, thanks for the comment.
I agree that hard core reference material that is printed on paper will continue to use tables. But wouldn’t it be better if the reference material were written in a structured format specific to the kind of reference it is, and then formatted as tables when it is published for paper, and potentially in some other format when published for mobile?