A printed manual is a luxury item. It costs both time and money to write, illustrate, prepare, and print. Every hard copy also adds weight to your shipping bills. Furthermore, guessing a print run in advance can be tricky—even if you have prior experience. Then, if you update your software before you have sold the entire first edition, you will have a lot of expensive stock to write off.
Until the late 1990s developers were considered cheapskates if they didn't provide a printed manual. Since then, the increased market penetration of laser printers has made it practicable to provide manuals in Portable Document Format (PDF). This allows users to print their own manuals or sections of manuals when they need hard copies.
The PDF approach obviously does not work for devices such as modems, as users can't access the documentation via the Internet until their connection is working. However, for most other software, it's a far more efficient solution.
With millions of people using the Internet regularly, online manuals and help are becoming the most practical way to deliver support. The beauty of disseminating support via the Internet is that you can make advanced versions available to everyone at the same time as you launch your upgrades.
Perhaps because of this, it is even more important to appreciate the distinctions between manuals and Help systems.
Even developers whose livelihoods hinge on implementation don't always appreciate that the function of a manual and a Help system is not the same. For example, with the growth of broadband, people are beginning to interconnect their offices and homes. Most of the hardware support (for ADSL modems, routers, firewalls, and so on) is being supplied as files for the user to print out. The only problem is that in many cases these manuals turn out to be verbatim copies of the Help programs. So, if a satisfactory explanation cannot be found in the manual, there won't be one in the Help program either.
As previously mentioned, people latch onto ideas differently. Remember even the most intelligent users can find new concepts hard to grasp. So explaining something one way in the manual and another way in the Help system can dramatically increase the odds of comprehension.
When a user summons screen Help he mostly wants to know how to do something or get out of a spot. It's pressing and it's immediate. He's looking for crisp, clear directions that he can remember when he returns to his main screen.
When he consults a manual, he usually has a certain amount of leisure. He wants to learn more about the program, perhaps in the following ways:
♦ To clear up something he couldn't quite grasp in Help
♦ To find out how the program came to be written
♦ How sequential functions work
♦ Whether there are any additional commands that would be handy
The complementary functions are not universally appreciated. If support is to be delivered via a single channel, all types of inquiry should be covered.
Manuals and Help systems are not like ordinary books. They don't tell a sequential story. Only a rival or a masochist would ever read either from beginning to end. Users consult them for guidance on specific needs. So each section needs to be coherent in itself and point the way to other useful sections. There are three popular approaches to support:
♦ Alphabetical—Easy to find if you use the search words your clients expect
♦ Functional—Useful where the functions are naturally separate
♦ Task-oriented—Where the entire activity aims at a specific result
Although each of these is laudable in its own right, all three ignore the initial task of orientation. Before they dive in, most users need an overview of the program. They need some sort of guide to know how to find their way about. They need to know which buttons to push to find all the commands, both crossways and downwards. They also need to be able to locate every embedded option and understand the program's purpose and functions.
Was this article helpful?