Modern Help Systems

In case you haven't been keeping up with the latest trends in Help systems, this section outlines the style of Help recommended by Designing for the User Experience . Modern Help systems should have the following characteristics:

Help topics are generally short and task-oriented . Large Help subjects are divided into smaller tasks to make them easier to read.
Help windows are small so that the user can look at the program while he is reading the Help.
Help hyperlinks connect only to useful, relevant information. There is no obligation to link to another topic simply because you can.
Screen windows and dialog boxes are not described with Help topic windows but with mouse-driven context-sensitive Help using the What's This? command.

This is in sharp contrast to the old-style Help, now referred to as reference Help. Reference Help was typically displayed as a near-full screen window, and it included so much information that the user really had to be motivated to want to read it. Large Help topics are intimidating and tend not to be read. Also, obviously, it took up too much screen space for the user to be able to read the Help and view the program at the same time. Often the Help text contained a screen shot of the program window that the user was already looking at, which makes no sense at all. Modern taskoriented Help systems are much more helpful to the user and much less oppressive.

click to view at full size.

Task-oriented Help corresponds much more closely than other forms of help to how and when users need help while using a program. For example, a user might want to know how to copy an image to the clipboard but is unlikely to ask, "How does the Copy command in the Edit menu work?"

click to view at full size.

TIP
Prefer task-oriented Help.

Printed Documentation

The trend is toward online Help and away from printed documentation. As user interfaces improve and become more standardized, the need for printed documentation decreases. It's been years since I have bought a software product from Microsoft with much more than 100 pages of printed documentation. I haven't missed it much. Since printed documentation is fairly expensive and difficult to modify quickly, you might want to follow this trend. Of course, providing printed documentation is a good idea in several cases:

If your customers need it You might have a product or be in a market that requires printed documentation. Note that beginning users are more likely to miss printed documentation than advanced users.
If your customers expect it You might have a custom or expensive product, in which case your customers might expect printed documentation.
If your software needs it Your program might be so complicated that it requires an introduction, tutorial, or other form of help that is significantly better when printed. The more reading the software requires to get the user going, the more the software needs printed documentation. It's more convenient to spend several hours reading a printed manual than reading online Help.
If your software needs a competitive advantage Printed documentation adds to a product's perceived value. It can be shocking to pay several hundred dollars for a product and receive only a disk or a CD-ROM. A printed manual makes the product seem much more substantial.

Many tools on the market can help you create Help and printed documentation from the same content. You might not want to bother. Although this approach certainly promotes consistency, it scores poorly in helpfulness. Needing help, looking it up in the online Help, not finding the information you need, looking it up in the printed documentation, and finding exactly the same useless information is extremely annoying. What's the point?