What is your primary media? Paper or the Web?

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?

Linear vs web organization of content.

Content designed to be read linearly (above) has a very different shape from content designed to be traversed through a web (below).

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.

Oxygen Docs

Much content is still designed for paper even when it is created in topics and presented online.

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?

, , , , ,

15 Responses to What is your primary media? Paper or the Web?

  1. Alex Knappe 2013/02/04 at 18:39 #

    Excellent post, Mark.
    You’re clearly pointing out something, that might rise some discussion.
    Personally I’m writing mostly for paper output (and that won’t change for years to come), as european regulations require paper output as most important documentation type. I completely agree with your statement, that content written for paper needs to be different to content written for the web. I’d also go a step further and say that content for every output should be different to the other types of output.
    Mobile output should differ from web output and from paper output. Video output, you say? Same thing? Augmented reality? Guess!
    Singlesourcing – as it is done today – is riding a dead horse. Are we ready to move to a new form of singlesourcing, yet? Sadly no. We’re still living in a text-centric era. All our tools base and evolve on creating texts for different outputs, but do no help us to diversify into different types of media.

    What we would need to adapt to the fast changing and expanding world of new output media, is a descriptive language that generates output as needed. XML might be the base this could be built on, but I’m not so sure, if it would be sufficient.
    DITA, Docbook and the likes are a relic of a text-centric approach. We need to leave them behind as what they are: an outdated attempt to singlesource content, that shouldn’t have been singlesourced in the first place.
    A new approach would most likely be similar to a programming language, with interpreters/compilers for different outputs, using standard and self-defined libraries and includable modules for specific needs (describing machinery or software?)

    • Mark Baker 2013/02/05 at 17:05 #

      Thanks for the comment, Alex.

      I’m with you for the most part, but I don’t agree on mobile. My choice of mobile vs desktop is not usually based on what I am doing, but where I am and which device is available to me. I hate it when mobile gives me different content from desktop. We do, of course, need to get designs that work on both mobile and the desktop, but let’s not separate the content, at least, not in the general case.

      But on the need for a more descriptive language, one that describes the subject matter semantically, and that is processed in a more programming like way, rather than by the mere application of styles, yes, I’m with you there.

  2. Ray Gallon 2013/02/05 at 09:36 #

    Mark, great question – but the choices are too limited. My primary medium is neither paper nor web – it’s software interfaces. I work on embedded user assistance a lot of the time. Depending on the product and the type of interface it has, the result is more or less like online help, but it isn’t anything unless, at design and conception phase, the user assistance is integrated. What the technical communicator produces, then, is no longer “documentation” nor “manuals” nor, many times, even “help” – though that’s a rarer case.

    At its best, when it’s done right, what the tech comm produces is her or his contribution to the user interaction design, and its interface.

    Of course, this can’t be “designed” in a silo, apart from the rest of it. And the content strategy used in the UA must be coherent with that in things as mundane as error messages, screen labels, terminology, etc. What? You say, “Content strategy in error messages?” – you betcha, I respond. Knowing, of course, that today this is a pipe dream for most of us – but knowing, too, that it’s actually very important, if we want our software products to be usable.

    In short, every screen is screen one. Every page is page one. And there, I agree that EPPO – or ESSO – content can more easily be put into pdf/paper format than “books” or “documents” can be turned into embedded, effective user assistance.

    • Mark Baker 2013/02/05 at 17:13 #

      Ray, that is a great point. Embedded user assistance is indeed another category and one that deserves much more attention that I think it currently gets.

      What I think we will see — or at least we should see — is the disappearance of help systems as we currently know them, with the content going either to embedded assistance or to the web.

      Embedded assistance can never be comprehensive, by its nature, so there is still a role for more comprehensive information. But the place for that more comprehensive information is on the Web, where it can integrate with all the customer-produced information. People are simply going to stop looking to “the help” as an intermediate information source. They are going to start with the interface, and then go to the web.

      The most important frontier in embedded assistance, I believe, is to make it situationally aware. Indeed, without situational awareness, embedded assistance is just a help panel you can’t hide — more annoying than helpful.

      Making it situationally aware, of course, means making it behave like data, and that means structured markup of some sort.

  3. Ray Gallon 2013/02/05 at 09:39 #

    Wish I could edit comments – that should read, of course,

    “it isn’t anything unless… the user assistance is integrated

  4. Pamela 2013/02/05 at 14:23 #

    I work, design, and write design for the web only using Confluence. I love it! Self-contained topics, no heavy production process, immediate visibility, immediate error correction (no waiting for the next cycle of PDFs to go out with the next release). It’s great!

    • Mark Baker 2013/02/05 at 17:18 #

      Hi Pamela.

      Yes, where tech comm has actually adopted the Web as a medium rather than just a delivery vehicle, it has done so with Wikis. Wikis are a natural Every Page is Page One media, so I am very encouraged to see the spread of Wikis in tech comm.

      Of course, being a structured text guy, what I really want see is the adoption of structured text in generating EPPO content. Right now, it is really the empty quadrant. We have structured and unstructured authoring of books, and unstructured authoring of EPPO topics (on wikis), but the structured/EPPO quadrant is pretty sparcely populated right now. Need to change that.

  5. Ray Gallon 2013/02/06 at 03:36 #

    Mark, thanks for fixing my post 🙂

    I agree with your notion of embedded plus web. Our UA needs to be searchable, and needs to come up first – not so we control it, but because our job includes integrating information we get from SME’s and developers, marketing, and users. Call it moderated crowd sourcing, if you like, but the crowd includes people inside as well as outside the producing entity.

    So here’s my secret tech comm heaven: Someone creates wiki software that automatically structures the inputs of contributors – sort of Mind Touch meets XML, if you like. Ideally, as you have remarked in a different post, this structuring should be transparent for whoever is writing. All we need do is get the right metadata from the contributor, in a natural language format. We could then pull it into whatever structure we wanted – even DITA 😉

    Once we have it in our “publishing” format (which, as you suggest, might also be transparent to the tech comm), the tech comm, as a specialist, can vet the various contributions and verify their accuracy, compliance with regulatory needs, if that applies, and check for overall efficiency, usability, and utility. If it passes, it gets republished in the “official” UA. The curation role is obvious, here.

    One additional comment: “embedded assistance is just a help panel you can’t hide” – not if you’re doing proper progressive disclosure. UA can be embedded without getting in the way – I’m doing it. That won’t change the need you state for linking to more detailed information. Today, we’re still doing that in something that resembles help panels. It should be on the web, as we both have articulated.

    • Mark Baker 2013/02/16 at 13:44 #

      Thanks for the comment Ray.

      I agree that the writer can play a curation role, but we have to recognize that just because we choose to curate, does not mean that the user will choose to use us as their curator of choice. I think our first goal should be to create curatable content — by which I mean both content that is worth of inclusion, and content that is easy to include.

      I’d also question the inherent need for integration of all these sources. David Weinberger characterizes the Web as a collection of “small pieces loosely joined”. It is the looseness of the joining that makes it powerful. New content is inserted into the loosely joined set simply be being created and made accessible to Google.

      It is impossible for a writer to keep up with that, so curating everything is not possible, which means that any one curated source is always less complete than the uncurated Web. This is why people increasingly skip the help and go straight from the interface to the Web.

      Ideally, of course, you want the Web search to land them in your own content. But that is something you can only influence by creating the best content available on the subject.

  6. Ruth 2013/02/09 at 01:07 #

    Hi Mark,

    For the last 15 years, at just about every place I have worked we have produced doc sets in both HTML (or HTML Help) plus PDF, and in all cases we optimized for HTML. PDF was provided in case the reader wanted to print (or in one company our HTML had so many dinky DITA topics that readers hated it and preferred to read the PDFs).

    My thinking has always been that when you produce HTML as primary with PDF secondary, you don’t want the content or structure to diverge between the help and PDF, because it confuses the reader: they think the content is different and so they feel they have to look for information in both places. (I confirmed that this problem was happening by doing customer research.)

    I’m wary of adding complications to a doc set unless I can prove there’s an advantage to the reader. Tom argues that new users might be more inclined to read PDFs; there should be a deliverable aimed at new users to solve that problem.

    • Mark Baker 2013/02/16 at 13:54 #

      Thanks for the comment, Ruth.

      I tend to agree with you. With HTML as the primary, you should probably provide everything in PDF — or nothing. WE live in a multi-device world, and my choice of device is more often based on where I am than on what kind of information I am looking for. I want the same content available on all devices, and PDF (as virtual paper) is just another device.

      However, keeping the structure constant between the HTML and the PDF works only as long as the HTML is sequentially or hierarchically organized. If it created as a true hypertext organized along multiple axes, then the structure won’t linearize for PDF, and you will need to create some other form of linearization for the PDF output.

  7. Erika 2013/02/11 at 09:20 #

    Excellent question. I am thinking about this for a long time now, but have not found the right web-based ‘entity’ or ‘container’ for holding all the information about a given version of a given product, not to mention tools that would help us produce them. Although we search information differently, I’m not sure we learn differently. When you want to learn about a new product or even a feature, just looking at the ‘linear’ hierarchy gives you a mental overview.
    I’m starting to look at wikis as I feel this is a possible direction. Pamela can provide a link to a good example?

    • Mark Baker 2013/02/16 at 14:08 #

      Thanks for the comment Erika.

      Yes, in a traditional book, the TOC could give you a mental overview of the subject. I wrote a blog post about this a while ago (http://everypageispageone.com/2012/06/11/whats-hiding-in-your-toc/). In that post I argued that bursting books into topics can often leave the reader rather at sea because something of the big picture was not expressed explicitly by the text of the book, but was implied by the structure of the book and could be gleaned from looking at the TOC.

      In a true topic-based information set, the need for an overview of the subject has to be met in a different way — by an overview topic.

      This is why I think it matters so much to decide what your primary media is going to be. You can’t make good topics by bursting books. And you can’t look to the navigational devices of books to provide effective navigation on the Web.

      Wiki’s can certainly work for this, but you have to learn to use web-line structures to make them effective. Look at Wikipedia. It organizes content primarily through linking, templates, and categorization, and manages to make one of the world’s largest content sets highly navigable and highly usable by these means.

Trackbacks/Pingbacks

  1. Are You Googleable? | Rant of a Humanist Nerd - 2013/02/07

    […] comment I made to one of Mark Baker’s recent posts, What is your primary media? Paper or the web? led to an interesting discussion about embedded user […]