"Let me describe a familiar user assistance experience. A user installs a new application, and when the user wants Help, the application directs her to the user documentation on a Web site or CD-ROM. What the user finds there is a PDF file containing the manual—or a collection of PDF files, representing a library of manuals, including a user guide, configuration guide, troubleshooting guide, and various references. And the layout of each of these PDF manuals is exactly the same as if it were a printed book. This raises an interesting question: If we’re giving manuals to users to read online, why do we design and write them for paper?
I’m not down on every use of PDF files online. Campus maps, article reprints, and my aunt’s Christmas letters all work quite well as PDF files. What I want to challenge in this column is the use of PDF files for distributing user assistance online, in the form of large books.
Use the following checklist to see if I’m talking about a kind of document that is near and dear to your heart.
* The online document includes small topics—often called covers. Sometimes, these topics, though brief, use a very large font, so they convey about the same amount of information you could present in a single heading in a traditional online document. We call this kind of topic a front cover.
* The document comprises pages—those arbitrary boundaries that determine how much of a topic’s content a user can view at once. What is on a page depends on how much of that content fits within an 8.5 x 11-inch rectangle—even though this boundary in no way approximates either the size or the aspect ratio of a computer screen. So, topics sporadically interrupt themselves, requiring a user to manually intervene by scrolling to continue reading the same topic. We call these sudden interruptions to the reader’s flow page breaks.
* Topics are grouped into sequentially numbered sections called chapters. The chapter numbers that appear at the tops or bottoms of all pages further reinforce their sequence. The sequencing of chapters usually corresponds to the order in which a writer expects users will need each topic—or intends users to read them.
* Some of the pages identify themselves with Roman numerals and others with Arabic numerals as page numbers. This can prove helpful—once a user realizes Roman numerals designate topics with no useful content whatsoever—which we refer to as frontmatter.
* When a document switches from using Roman numerals to using Arabic numerals for page numbers, it often starts counting over again from 1—while the document viewer’s Print dialog box does not. Therefore, printing a particular range of pages requires users to do math in their heads.
* Those little page numbers seem to jump around—sometimes appearing on the right of the screen and sometimes on the left.
* The placement of text on alternate pages also shifts left and right, with a close correlation to whether those little numbers are odd or even. On the insides of the pages of print books, gutters allow space for the binding. To online readers, gutters are simply annoying.
If this checklist identifies the characteristics of online documents you’ve experienced, you’re probably starting to see what is driving my desire to move away from PDF manuals. None of these characteristics has any logical justification in the context of finding and reading topics online. If you were creating online documentation from scratch, would you have identified any of these characteristics as requirements? If PDF manuals are the answer, what was the question?
Why Do PDF Manuals Still Abound?
The PDF manual was born when a software product manager asked, “Why am I paying good money to print documentation users don’t read, when I could instead provide the same documents electronically for them not to read?” I am sure it was not a technical communicator—wedded to the myth that users were reading the manuals—who discovered this principle of economy, but we did acquiesce too easily. Maybe creating PDF manuals seemed like an easy transition into the scary world of online information, while still remaining grounded in the familiar skill set of conventional book design. Here are some dialogues that show possible rationalizations for PDF manuals:
* “Users want hard copy. So, we should give them hard copy.” “Too expensive” is the rationale, “Users won’t pay for hardcopy.” Then, the real truth is users don’t value hard copy.
* “Users can search the PDF file online, then print just the relevant sections.” If that is our assumption, printing should be easier than printing a PDF file is. Users should be able to designate what they want to print by topic, not by ranges of page numbers. If a topic spills over several pages, why should the user have to figure out what pages, then do the page number math? If the last page continues onto another topic, why should a user have to waste ink on a topic that is of no interest. Once again, the PDF realities just do not match any logical requirements.
* “Books fit a metaphor users are comfortable with.” Most users don’t use real books all that well. Why should we think they’ll suddenly get it when a book is online? The hard reality is that books are a metaphor writers know well. It has little to do with what users are comfortable with. Books are simply what writers are comfortable writing." (Continued via UXmatters, Mike Hughes) [Usability Resources]