Which media is your principal design target? Most tech pubs organizations deliver to multiple media, but which one do they design for? Judging by the content I see every day, most organizations are still designing for paper even when they mostly deliver to the Web. If you are delivering primarily to the Web, shouldn’t you be designing primarily for the Web?
Tom Johnson’s latest blog post, Single Sourcing and Redundancy, ask the important question of what to deliver to each media. Do you deliver different content to paper, help, and Web, or do you deliver the same content in each media?
Tom does a great job of exploring the options, but if you really want to answer the question for your own organization, you have to first decide which is your primary media.
In the early days of online help, and also in the early days of the web, it was assumed that online was a secondary media. It was for quickly looking something up, not for answering big questions. It was assumed that if you wanted real information, you would pull out the paper manual and read it. The received doctrine, therefore, was that online content should be minimal and brief. Paper was the primary medium; online was just a minor supplement.
If you could afford to, you were supposed to write separately for help. Of course, nobody could afford to, so single sourcing became a necessity, leading to the question Tom addresses: which bits of content from your single source go into each format.
The use of online media, specifically the Web has increased dramatically over the last decade. More and more users seek help for a product not by digging a manual out of whatever drawer they threw it into when they opened the package, but by Googling, not only on their desktop computers, but on tablets and smartphones.
Are we designing content that works when people find it via a Google search? We have been single sourcing content for a long time now, but what design principles drive the design of the content in that single source? Is it book content, or online content?
We should be clear about how different the two are. Merely abstracting the formatting aspects of the content so that it can be transformed into HTML or PDF does not make the content independent of its target media. Content can be written in a way that is optimized for linear paper presentation or in a way that is optimized for the Web, but not for both.
(Just so we are clear, if you are designing for PDF, you are designing for paper, even if you don’t print it yourself. PDF is an electronic paper emulator. It emulates paper on glass. This is what makes it a great pre-press format, but it also means it is not an online format. PDFs may be delivered on the Web, but as a format, it is not of the Web. It belongs to the paper world.)
The paper world is a world of linear information. One page succeeds another in a fixed order. The Web is a hypertext media. The user is free to navigate from one topic to another in any order they like. In the paper world, the book is a closed container, it covers what it covers, and that’s all there is. The Web is open, it contains almost everything and it is constantly changing. A book is a duck pond; the Web is an ocean.
You cannot design information in a way that is neutral about the issue of whether it will be part of a closed stable linear information product, or a collection of nodes on an open volatile web. Content designed to be read sequentially will never work as well when accessed at random. Content designed to be accessed randomly will never read as smoothly when read sequentially.
Most of the content we find on the web is of the non-linear variety. Most of the content that tech comm puts on the web, however, is still of the linear variety. It is written as a book and then burst into separate, but sequentially linked pages. The most usual process for doing this is to write in FrameMaker and to create Web output using Webworks Publisher. This creates a very distinctive appearance in online media, in which you will often find a page containing nothing but a title, a single introductory paragraph, and a [Next] button.
Interestingly, a switch to “topic based writing” often does nothing to change this. It is remarkable how much a lot of Web content produced using DITA looks exactly like content produced by the FrameMaker/Webworks combo: you still get topics that consist of nothing but a title and a single introductory paragraph, usually followed by a list of “sub topics”. And, of course, a [Next] button. Content is written in “topics”, but still designed as a book.
Tech Comm content is still being designed for paper, and then exported to the Web, or to help. Paper is the primary media, help and the Web are secondary. Information is designed to work on paper, and content is accommodated to help and the Web as far as its fundamental design allows.
It is time — long past time — to change this around. It is time — long past time — to start designing content for the Web first and then accommodating it to paper (PDF) as far as its fundamental design allows. Our customer’s tastes and information seeking habits have long since made this switch. Every other information-providing function has long since made this switch. It’s time — long past time — for us to make it too.
How do we change from designing for paper as a primary media and start designing for the Web? Fundamentally, we have to stop thinking in linear or hierarchical terms. We need to start producing Every Page is Page One topics that are free of linear and hierarchical dependencies and that link richly to other topics, both inside and outside our information sets.
You can still create PDFs from a set of Every Page is Page One topics. Will doing so create a book that is as optimized to work like a book as if you had written it from scratch to be a book? Probably not. But the Web and help output that was created from book-oriented material never worked even remotely well as help or Web content. You can’t expect your secondary media to work as well as your primary.
But it turns out that books created by assembling Every Page is Page One topics work much better as books than burst books ever did as Web pages. After all, a reader does take a linear path through a collection of Every Page is Page One topics, it is simply a path of their own choosing. Stringing EPPO topics into a book creates a similar path, just one that is of the writer’s (or information architect’s) choosing. And a book created from EPPO topics will also work better than a linear book when readers use it in a random fashion, diving in through the TOC or the index.
Writing for the Web first, and making books as a secondary activity, works better, and is more appropriate to the times, than writing for paper first and then making Web or help output as a secondary activity. It is really only due to paper having been longer entrenched, and our tools, habits, and processes being designed around paper, that we have not switched long ago. But it is time now — long past time — to make the switch.
What media do you design for primarily? And if your answer is not “the Web,” when are you planning to make the switch?