Ever since it became possible to view PDF files online via the Adobe Reader plug-in to a Web browser, a debate has raged about whether and how one should take advantage of this fact. While for many this debate appears to be over – Google now counts 1.2 billion hits for “pdf” – a fierce argument continues to fester among some self-described usability experts. This article examines the claims of those PDF critics and argues that the complaints are misdirected, and further, highlights some of the key reasons why PDF is the preferred electronic document format.
PDF critics
The leading proponent of the idea that PDF is, as he puts it, “Unfit for Human Consumption” is Jakob Nielsen (www.useit.com). In his now-legendary piece published in 2003, Nielsen lists his “PDF Usability Crimes,” claiming that the only useful function in Reader is the Print button.
Others with a less-emphatic opinion include Peter Abrahams at Bloor Research, who places the onus squarely on the content creator to manage the usability of their PDF files. Abrahams is entirely correct to do so. Unlike Nielsen, Abrahams is aware that all manner of usability enhancements are easily available to PDF files, requiring only a modicum of curiosity from document authors. He points out, however, that some of the tools in Acrobat – especially those pertaining to accessibility – are just too cumbersome to expect most users to bother.
This point is valid, but should not be overstated. The fact that it takes some effort to produce an optimally usable and assistive-technology-friendly PDF file-instead of a single-purpose, print-only file-should be no more surprising than the fact that it takes some effort to design and lay out a document. If one approaches the design and layout process itself with accessibility in mind, the resulting PDF will reflect this out of the box, reducing or even eliminating the need for tweaks to the PDF after creation.
Is there a case for Nielsen’s PDF ‘crimes?’
Before addressing the core of the anti-PDF argument on usability grounds, let’s take a look at the case for the defense in Nielsen’s crimes.·
Nielsen: “Linear exposition. PDF files are typically converted from documents that were intended for print, so the authors wouldn’t have followed the guidelines for Web writing. The result? A long text that takes up many screens and is unpleasant and boring to read.”
Reality:Long documents are long documents, whether in PDF, HTML or anything else. Unlike HTML, PDF documents-of whatever length-are self-contained and may be downloaded, e-mailed and so on with total reliability. The usability issue presented by such a document is easily addressed via the Bookmark feature, which is both fully standardized and easy to implement.
Nielsen:”Jarring user experience. PDF lives in its own environment with different commands and menus. Even simple things like printing or saving documents are difficult because standard browser commands don’t work.”
Reality:Anyone who has encountered a PDF more than a couple of times is far smarter than this, and understands that a PDF is not some just another page, but rather, a document made available via a hyperlink. It’s true that PDFs loaded into a browser are manipulated with an additional toolbar (that’s where you’ll find the Print button, Jakob) and they often are navigated by bookmarks. It’s silly, though, to pretend that these tools really confuse anyone but the most novice Web surfers – surely a dying breed. In any event, this problem is clearly self-correcting – the more PDF files are viewed online, the more familiar users become – just as with their browsers.
Nielsen: “Crashes and software problems. While not as bad as in the past, you’re still more likely to crash users’ browsers or computers if you serve them a PDF file rather than an HTML page.”
Reality:Nielsen has a point here, and I won’t quibble between genuine crashes (which rarely happen to Reader) versus nasty error messages or pages that won’t display. They all count as fatal errors to the vast majority of users – and that’s true for HTML as well; there are plenty of Web pages that don’t work in all mainstream browsers. In virtually all cases, however, the cause is merely an out-of-date version of Reader. Document authors and managers can address this in three ways, which taken together, are nearly 100 percent effective. One, by ensuring the PDF files they create are based on the PDF 1.4 specification (a simple batch process in Acrobat), they can ensure support for Reader all the way back to version 5. Two, open your file to make sure it’s not broken – much as you might preview any HTML page. Three, provide a link to Adobe’s Reader download page, and prompt users to download and install the latest version.
Nielsen: “Breaks flow. You have to wait for the special reader to start before you can see the content. Also, PDF files often take longer time to download because they tend to be stuffed with more fluff than plain Web pages.”
Reality: The Reader only has to launch once – just as your browser only has to launch once. Thereafter, Fast Web View-enabled PDFs open just as fast as Web pages. There’s a strong case to be made that for larger documents, well-constructed PDF files are easier to download and navigate than a similar volume of HTML. As for “fluff”-typical Web pages these days often far surpass 100kb per page when images and advertising are included. PDF files produced from electronic sources tend to average far less.
Nielsen: “Orphaned location. Because the PDF file is not a Web page, it doesn’t show your standard navigation bars. Typically, users can’t even find a simple way to return to your site’s homepage.”
Reality: While it is true (and a shame) that the hyperlink-capable bookmark, link and button features of PDF go largely unused, it has nonetheless been both possible and easy to include standardized navigation features in PDF since almost the beginning of the format. What is more, PDF files are far easier for non-experts to make navigable than HTML.
Nielsen: “Content blob. Most PDF files are immense content chunks with no internal navigation. They also lack a decent search, aside from the extremely primitive ability to jump to a text string’s next literal match. If the user’s question is answered on page 75, there’s close to zero probability that he or she will locate it.”
Reality: This “blob” is one of the most valuable innate features of PDF! It is precisely this self-contained, platform-independent, works-everywhere-the-same-way “blob” that first made PDF the natural bridge between the on-screen and printed worlds. As for the “no internal navigation”-as discussed, this is the responsibility of content creators, and one that is easier (outside of the accessibility issue) for average users to manage in PDF than it is in HTML. Nielsen’s comment regarding search is nonsensical-quality search engines index PDFs just as they do HTML, and most sites won’t facilitate a search restricted to a single document over a number of pages, as PDF internal search does.
Nielsen: “Text fits the printed page, not a computer screen. PDF layouts are often optimized for a sheet of paper, which rarely matches the size of the user’s browser window. Bye-bye smooth scrolling. Hello tiny fonts.”
Reality: There’s undeniable value in supporting printed-page applications, as Nielsen acknowledges. What he does not appear to understand is that PDFs may be optimized for both print and on-screen applications, which is more than may be said for HTML! Structured correctly, a PDF file may be reflowed to permit adjustable type size on screen (something many people think only HTML can do), and the same file may be easily deployed for print or on-screen use on both websites and mobile devices with good results. A fully accessible PDF goes beyond Reflow mode (Control-4), containing the logical structure needed to give even blind users comprehensive navigation of very long and/or very dense documents. Nielsen’s real complaint-and it’s a valid one-is that all too few PDF authors take responsibility for ensuring their files are as usable as possible.
The core of the argument
As we have seen, the essential problem with this criticism of PDF stems from the inability or unwillingness of the critics to discern between the capabilities of the format versus the manner of its implementation. In addition, they fail to distinguish between the relative ease of authoring PDF versus HTML documents, or ensuring the usability thereof. It seems that when speaking of PDF, they refer only to badly designed PDF. When speaking of HTML (by contrast), they refer only to well-designed HTML.
To condemn PDF on these terms is akin to arguing that since only a relative few good movies are released each year, films themselves must be a lousy art form. At best, this view is curmudgeonly, at worst, it’s ill-informed.
Where this complaint originates is perfectly clear. HTML pages on most business and institutional sites are typically created by professionals, or at least skilled individuals. To ensure uniformity and quality, new content is generally written or loaded via a strict template or content-management system. PDF files, on the other hand, may be and are created en masse by almost anyone for as little as $10 per desktop, from any software that can print.
HTML authors know they have no real control over printed outputPDF authors know they have both locked-in print performance AND a (potentially) Web-ready file.
| Content Authoring Paradigms | |
|---|---|
| HTML content | PDF content |
| Takes an expert to create a good-looking document from scratch. | No matter which application you use or how you use it, you can make a PDF that looks exactly like the original. |
| Authors do not expect detailed control over presentation. | Authors expect detailed control over presentation. |
| Authors prepare “raw” content for a deployment system. Responsibility for look, feel and performance is up to the Webmasters | Many authors create ready-to-go content themselves. Graphic designers tend to focus on the printed page. |
The result is very few controls or limitations on the content that may be delivered in PDF, and fewer still all the time (Adobe Acrobat 3D allows three-dimensional representations in PDF). As compared to HTML, creating PDF files is simple. Literally, the single click of a mouse will do it, and unlike HTML, the results are true to the author’s main intent (i.e. matching the design of their source document).
This is, in effect, Nielsen’s whole point. In his view, it’s just too easy to create a PDF. Anyone can do it, with any software they want, and that’s a problem. Even though non-experts can create PDF documents and (apparently) get something that’s “good enough,” they probably shouldn’t.
Conclusion
It’s not for nothing that people develop heavily designed documents, and the fact that Nielsen has no apparent use for graphic design can’t be taken as evidence that nobody else should either. On the merits, Nielsen is plainly wrong that the choice of PDF represents a usability problem. He is correct, however, in noting that PDF creation software doesn’t foster–and document creators aren’t sufficiently prompted to understand–the practices that definitively resolve all of Nielsen’s usability concerns as they pertain to PDF.
Rather than trashing the format, Nielsen should be cajoling document authors and managers to consider on-screen applications in their document designs–and to use the tools already under their noses to make better PDFs. Dismissing PDF as “unusable,” Nielsen misses the essential quality that makes PDF so popular–the fact that PDFs are very easy to make and very reliable for the purposes generally intended. PDFs are highly usable, Mr. Nielsen, even if they could be more so. That’s why people like ’em.
Originally posted on acrobatusers.com.
by Duff Johnson