PDF: Unfit for Human Consumption (Jakob Nielsen’s Alertbox)

PDF Usability: it’s still an extra file format to support and to open…

I have had people ask me what the difference is between online help & a PDF. I’ve also had people ask me why not just dump out a .doc file or a .PDF and have that stand as the help.

Self help = money saved in time

Quality documentation leads to less frustrated user interaction, such as emails or making phone calls. If you can also ‘eat your own dog food’ and your internal staff is comfortable reading its own company’s software documentation people can help themselves and not further burden the knowledge resources. It’s something that a lot of corporations lose sight of.

Sometimes it seems like oversimplification to just tell people the readability difference between a ready to print user guide and online help is apples and oranges.

It’s also been hard for me to explain the value proposition and frequently I’ve heard it said:

…well, you do want people to actually read the documentation, right?

…or this one said about call avoidance being, at the end of the day, the true success metric of both online and print documentation.

Who takes the phone calls if the usability of the product confuses people? That costs money, right?

I’m not satisfied with either comment which is why I’m still researching how to gently deal with the issue.

But in this context I’m referring to the ability to find information within the containerized PDF and the innate strength of context-sensitive help (CSH).

Context-sensitive help as defined from Wikipedia:

Context-sensitive help, as opposed to general online help or online manuals, doesn’t need to be accessible for reading as a whole. Each topic is supposed to describe extensively one state, situation, or feature of the software.

I’ve authored within a PDF to duplicate the same type of online help standard, however I ran into complex issues hyperlinking externally to reach that direct content. The build process takes the same amount of time as it does to bang out a help file within a Help Authoring Tool, and then my information is siloed within the PDF.

The results of my research into PDFs in documentation back in 2002 led to my suggestion to the eHelp Executive team to implement a PDF ‘ripper’, which they implemented within version X4 and is still in use today through RH7.

The concept was that pulling content from rtf, pdf, doc, text, and html files makes a workflow much easier when aggregating content, and saves the help author the tedious job of copying, stripping the formatting by pasting into notepad, and pasting back into a topic file in your Help Authoring Tool. This was back in the HTML days, long before XML made that even easier to store content without storing the inherent styles.

Flash Forward Five Years

This PDF bugaboo of mine has a great deal to do with my shrugging of my shoulders about the embedding of Flash files, demos, audio, and now with the Adobe TCS Acrobat 3D files within Acrobat PDF files.

I’ve never tried to print an audio file… or a product demonstration on Flash. How does that work again?

Well, don’t take it from me, ask Jakob Nielsen, author of Alertbox

To get into the opposing side of PDF usage online, here’s one of the most famous articles online… Alertbox: PDF: Unfit for Human Consumption (Jakob Nielsen’s Alertbox)

Summary:
Users get lost inside PDF files, which are typically big, linear text blobs that are optimized for print and unpleasant to read and navigate online. PDF is good for printing, but that’s it. Don’t use it for online presentation.

PDF is great for one thing and one thing only: printing documents. Paper is superior to computer screens in many ways, and users often prefer to print documents that are too long to easily read online.

For online reading, however, PDF is the monster from the Black Lagoon. It puts its clammy hands all over people with a cruel grip that doesn’t let go.

So since this article was written back in 2003

…Update 2007: Our new studies keep finding the same problems with PDF in online interfaces.

I’m not going to give you a problem without the solution…

And now here’s the Alertbox article how to fix that issue: Gateway Pages. I’ve seen this approach used throughout the UC Davis agricultural data website, along with several Federal information repositories such as the USDA. This has been adopted as a style within several corporations, including Adobe’s Investor Relations data.

Summary:
Spare your users the misery of being dumped into PDF files without warning. Create special gateway pages that summarize the contents of big documents and guide users gently into the PDF morass.

Ideally, companies would reformat each type of information for online use. It’s actually not very expensive to, say, create a set of Web pages for annual report information as long as the Web design is done while the annual report is being written. The cost comes when companies have a glossy annual report already finished and then say, "Webbify this."

If you distribute documents for printing or if you absolutely have to repurpose existing content into a substandard user experience, at least protect your users from nasty surprises. Create a gateway page for each PDF document and make sure that users are always guided through the gateway:

• All links to the information should be to the gateway page; none should go directly to the PDF file.
• The gateway page should include a short summary of the PDF file so that users can assess whether they want to go to the trouble of entering PDF-land.
• The gateway page should clearly warn users that they’ll be getting a PDF file. It should also state the file’s page count and download size.
• Break big PDF files into sections and offer separate links into each one, with a brief summary of the content next to each link. Also, provide a link to a single file that includes all pages, and tell users to use this link if they want to print the document.
• Consider adding instructions for how to download the PDF file without the annoyance of having it open in the browser. Unfortunately, this is difficult for average users to do with current technology; it would be nice if there were a special type of link that would always download a file rather than displaying it.

If you refer users to PDF documents on other websites that follow these guidelines, always link to the gateway page, not directly to the PDF.

Finally, on the gateway page, follow the guidelines for opening PDF files in new windows.

Obviously Jakob does not like PDFs and he’s not alone in that assessment. I’s one that Adobe has worked hard to address, and I have to give them points in what’s occurred over the past five years since I really dug into the Acrobat workflow.

Not withstanding my agreement with most of Jakob’s points I am surprised that he still doesn’t upgrade his assessment with this year’s release of Acrobat.

He also has this statement about opposing PDF blobs of content found within his 200th article posted a few years back:

Fighting Multi-Million-Dollar Interests

Several times over the years, the Alertbox has taken on entrenched interests backed by hundreds of millions of dollars. The result has usually been victory, though it’s too early to tell for my fight to decimate PDF blobs.

The reason I’ve often won — despite that fact that usability enemies are far better funded — is that I simply tell the truth as I see it in user research. I am not beholden to any special interests, so when I observe that humans behave in a certain way, I’m free to say so and to explain the industry implications. Human nature is very hard to change; companies trying to impose technologies that go against it often lose.

From PDF blobs to short entried blogs: Jakob on Blog Content

Jakob also doesn’t like blogging just for blogs sake. He recommends full length articles versus quick single paragraphs. Of course his caveat is that he’s in a consulting business with 3 to 5 years of readership prior to anyone attending his usability conference, and that if you’re selling a commodity such as pistachios, short blog postings make more sense.

But… Now some of you may understand that he and I do agree with the length of articles within the blog, along with the PDF blob concept.

Last but not least.. Why Good Documentation is a MUST

From Making documentation a commodity by Communications from DMN

Good documentation — whether a manual, a help file, a wiki, or a knowledge base — enables a user to solve a problem for themselves, rather than make a costly support call. It saves money by allowing support personnel to focus their attention and energies on the more difficult problems that users may encounter; ones that aren’t or can’t be covered in the documentation.

Even more than that, good documentation can be a sales tool. In a couple of cases, the documentation that I wrote was mentioned favourably in software reviews — as an effective guide to configuring and using the applications, and also as a guide to the capabilities of the software. When I left one company, a salesperson made a point of mentioning that the user guide helped him better understand the software, which helped close a couple of sales.

This opinion may be contrary to the trends in the market. Get ready for an increased market push from India in Technical Communications outsourcing.