Councils -- Kill your PDFs

7 June 2012

Councils have far too many PDFs on their websites. It’s time to scale them back, make those that remain easier to use, and to plan for a future where PDFs are entirely unnecessary.

What’s wrong with PDFs?

Browser usability

PDFs cause serious usability problems for many users. If your website contains large numbers of PDFs it’s really got two very different kinds of “pages” – HTML web pages and PDFs. Each of these works very differently. As with all usability problems, the pain is felt particularly acutely by less experienced users – the very people that councils should be making an extra effort to help use the internet confidently and effectively.

There is no consistent way that PDFs are handled by a web browser – it just depends on how the browser and the user’s computer is configured. When a user clicks a link for a PDF on a desktop browser, one of several things might happen:

It might download as a file to the user’s computer (typically also giving a scary security warning message)
It might open up in a viewer application (e.g. Adobe Reader) within the current tab
It might open up in a viewer application in a new tab
It might open up in a stand-alone viewer application detached completely from the browser

The user might also unexpectedly get a focus-stealing software update message from a viewer app like Adobe Reader – something which will also annoy and confuse some users.

In most cases the back button won’t work (i.e. pressing Back in the browser, if you can find it, won’t get you back to where you were). Many inexperienced users find it difficult to navigate between tabs, windows and applications. PDFs make it impossible to guarantee that all the action stays within the user’s current browser tab. Break the back button and you take away many users’ primary navigation tool.

Search engine woes

PDFs also cause problems with search engines. Depending on how you’re serving your PDFs, they might not be indexed in search engines at all. (One council I checked only had five PDFs indexed by Google. The real number on the site is far higher.)

Even if your PDFs are indexed by search engines, this often causes other problems. Someone clicking through to that PDF from a search engine results page is taken straight to the PDF (downloaded, opened in a new tab/application, or whatever). They’re not visiting your website. They don’t see your branding or navigation. They don’t see the context in which the PDF is linked within its parent web page. And very often PDFs remain on your website, still indexed by search engines, long after their parent pages have disappeared. You’re serving up out-of-date, context-free information that’s very likely to be misleading.

PDF handling on smartphones and other mobile devices is also haphazard. Assuming the user can view the file at all, it could be very difficult to read and navigate on a small screen.

PDFs can also cause problems for more experienced users when they’re implemented badly, which they often are. Typical issues are:

The file has no meaningful filename, making it harder to find once it’s been downloaded. Often the filename is just a number or a random string generated by the CMS.
Long PDFs don’t include bookmarks, tables of contents and internal linking, making them very hard to navigate.
Visible page numbers in the document itself are inconsistent with the PDF’s natural page numbers, often because they’ve been displaced by extra front material such as a cover which has been added later.
Pages often have the wrong orientation, e.g. landscape pages in a portrait document are presented in portrait. This is common in planning documents where maps and plans are unreadable on the screen unless you want to tilt your head to 90 degrees.
The document lacks appropriate metadata: The publication date, revision number, the URL where it can be downloaded again. Often even the name of the publishing organisation is missing.

How to fix your PDFs

PDFs should only be used when they’re the most appropriate document type. Often it’s just a lazy way to get something online that’s been written in a word processor.

Councils should publish and enforce internal standards for PDF use, making it clear when PDFs are appropriate and when they’re not. And when PDFs are used, they need to pass quality standards.

When should a PDF be used?

When a document is primarily designed to be printed, e.g. a poster for an event or a form that should be completed in handwriting.
For documents that are too long for a single web page, e.g. over 2000 words or so.
For any other documents where the precise layout is essential and where it cannot otherwise be efficiently created as a web page.

All other PDFs should be converted to standard HTML web pages and the PDFs deleted from your servers. Make sure that your website should uses a print stylesheet so that pages print cleanly at sensible size and without extraneous headers, footers and sidebars.

And for bonus points…

Over time, your criteria for acceptable PDF documents should get shorter and the number of PDFs on your servers should get fewer.

Forms designed to be printed and handwritten should be migrated to web-based forms.
You should develop or acquire software to publish long, multi-chapter/section documents as HTML web pages. At a very minimum, each chapter/section should have its own URL and therefore be sharable/linkable at that level of granularity. You could also give each paragraph its own URL using fragment identifiers. Here’s an example I created.

Summary

PDFs make your digital services considerably harder to use, especially for less experienced users. They should be avoided as far as possible.
Audit your published PDFs and remove those that are inessential. Migrate the content to HTML where necessary.
Where you can’t avoid publishing PDFs, devise and enforce strict quality control standards to make your PDFs more usable.
Improve your web publishing tools so that more content can be published as HTML rather than PDF in future.