Infodeck

When I rant on at my colleagues about the evils of Slideuments, I do hear a useful push-back. Many people now like to communicate through slide decks that aren't meant to be used for presentations, just to be read. People like me can snark about managers these days being unable to read anything that doesn't look like a bullet point, but there are advantage to these infodecks.

• You can use spatial layout to help explanation
• They discourage long prose that people don't read
• It's easy to include diagrams as primary elements in the communication

All this can lead to a document that's more approachable and easier to communicate information than a traditional prose text would be.

For a list of infodecks on martinfowler.com, see the infodecks tag.

If a deck is intended for reading and not for projection, then I don't count it as a slideument. Slideuments are bad because they try to do two different things, but an infodeck is there only for reading, so can be done well. Often, of course, they aren't but that's a problem in the execution rather than the fundamental concept.

Infodecks are an interesting form to me, if only because it seems nobody takes them seriously. Most users look at them as something they just knock up with PowerPoint, and writers with pretentions to seriousness (such as myself) consider infodecks to be beneath us. I'm beginning to think we should take them more seriously. We should think and talk more about how to make them effective as communication vehicles.1

One reason that these are likely to grow is that increasingly we are communicating on computer devices and not using paper. Modern computers have bright multi-color screens, and aren't worried about conserving paper. So a colorful, diagram-heavy approach that uses lots of virtual pages is an effective form of document - especially as tablets become more prevalent.

So over the last year or so I've begun exploring using infodecks as first-class forms of communication. You can see a couple that I've produced so far

• An introduction to NoSQL, which is a PDF
• Developing software for multiple mobile devices, which is HTML

Using just a couple of examples is only enough to make tentative conclusions, but is enough to make me want to continue exploring this medium. Both of these infodecks are relatively high-level, non-technical pieces, indeed I visualized one of our senior sales managers as part of my target audience. Infodecks naturally seem to fit to this kind of audience, but I want to also try them for something more technical in the future.

I think PDF works best for most people, since often these will be emailed around. I used Apple's Pages application for the NoSQL infodeck, and I think a page-layout program is a better fit for the form that a presentation program such as PowerPoint or Keynote.

For my purposes, however, HTML is a better fit. I write mostly for this website, and HTML is the language of the web. Also with HTML I have the option to use dynamic elements, such as animation, which isn't possible with PDF. The downside is the lack of tools. There are tools out there to do HTML slideshows, but they are mostly aimed at live presentation tools using the Bullet-Riddled Corpse anti-pattern. Infodecks have different needs to live presentations and even though bulleted sentences are less of a problem for infodecks, I want to use many other techniques.

However it does make sense to use existing HTML based tools as a base. For the multi-mobile deck I originally used deck.js which combines a good set of basic slide functionality with a nicely extensible architecture. For later decks I explored adding animation using animation extensions to deck.js done by Rémi Emonet. Rémi was extremely helpful at sorting out various niggles that are particular to my rather odd usage. However I hit an impassable road-block - deck,js, like most HTML-based presentation tools, loads the whole slide deck into memory. While this makes sense for live presentations, it sadly crashes devices - such as my iPad 1 - with the decks I was working on.

As a result I had to write my own javascript platform for hosting the decks. This just loads a few slides at a time, so trades resonsiveness for less memory usage.

I don't ever like writing HTML directly, so I compose the deck using my usual approach - a custom XML vocabulary that I transform into HTML using an extension of my usual transformation toolchain.

As well as working on the toolchain, I'm also working on the compositional style to use for infodecks. So far a core element is having a lede-and-details approach to the text. Most slides have a lede, a single sentence in a large font that summarizes the narrative. More details appear in text blocks. The idea is that the reader can get a good sense of the what the deck says by skipping through the slides just reading the ledes. When they want more detail they can read the more detailed text. The limited feedback I've gathered so far seems to support that this is working as I intended.

The detail paragraphs are link bullets, but can be longer than what people put in live decks. I think of them as short paragraphs rather than bulleted sentences.

Diagrams are key to making the infodeck style work. For the HTML toolchain, I've been focusing on using SVG. I did this partly because this way everything scales nicely, but also because I can take advantage of the fact the SVG objects are DOM objects that I can manipulate through css and javascript.

(I originally posted the first edition of this entry on December 19th, 2011. I've updated it with my recent thoughts on building Infodecks.)