Using PDF for a help system is a great idea – providing you don’t make some basic mistakes, keep true to what PDF is, and don’t force it to be what it isn’t.
Some general rules for implementing Help documentation in PDF format might go like this:
1) RESPECT THE PRINTED PAGE, aka, think about what happens if the user prints the document. This means, always plan the page-size for the occasion. US Letter? A4? Will they need page or section numbers? Maybe you prefer landscape viewing on-screen? Maybe you want to provide BOTH screen-optimized AND print-optimized documentation?
What you DON’T do in PDF is ignore page-size. A PDF is a page-oriented thing. Work with that, and you’ll be happy.
2) Consider how the documentation will be used, and where. If you anticipate largely on-screen use, then layout the documentation in a screen-friendly landscape model, and use screen-friendly (and tested) font selections, sizes and styles, based on exactly how your document will display. You’ll want to consider whether you want the toolbars or even menu bars to display on your document. By hiding the toolbars and providing your own customized navigation tools, you can help users “dig into” your content and get what they need far faster than with the “generic” Reader interface.
If you anticipate (or prefer to suggest) that users should print the documentation, or relevant subsections thereof, then clearly you’ll want to use printed-page friendly layouts. When you do this, consider whether you need to accommodate users from different countries. The European A4 page-size standard is longer but narrower than the 8.5″ x 11″ of US Letter standard. It’s safest to presume A4 “slimness” and US-Letter page-lengths… assuming that you don’t intend to support both page sizes independently!
On the other hand, you might want to include layouts for BOTH onscreen and printed applications, or design in a way that accommodates both in the same design. Either way, it’s worth some thought. If you decide to develop separate screen and print-oriented layouts, know that you can easily combine them in a single PDF document, and provide a way for users to BOTH read the Help file online AND simply click a button to be offered a print-formatted version of the current section. Pretty cool!
3) ALWAYS bookmark the PDF down to the lowest practical organizational level in the file. Your Word file must be fully and carefully structured – and you must also be a little lucky – in order for Adobe Acrobat’s Convert to Adobe PDF macro to work perfectly, especially on larger or more complex documents. Failing that, there are excellent 3rd party tools such as ARTS’ Aerialist Professional, ISI’s Compose and others for adding highly structured bookmarks to PDF documents.
I cannot emphasize this point enough. There are far, FAR too many PDF manuals out there sans bookmarks. Disgraceful! See my article about “Tightship Associates” for more details on what bookmarks can really mean in simple productivity terms.
The lack of Bookmarks is a serious drag on the economy, dang it!
4) Once bookmarked, ENSURE that bookmarks are visible to the user when the file is opened. A trivial point? Not at all… our testing has shown that only 20% of files out there with bookmarks actually DISPLAY the bookmarks when the PDF is opened for viewing. It’s a simple fix, people. File >> Properties >> Initial View; take it from there.
An example: We might add “print this section” buttons to a manual, but for a section that includes a form, perhaps we do something different. Here, we might add a special buttons to the form that print JUST the form. Then, we change the section-print button to skip over the form. Why? Why not? It’s EXACTLY the sort of thing end-users determine that they want and need want. That’s up to them, we just build it. And so can you.
by Duff Johnson