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
. Modern Help systems should have the following characteristics:
Help topics are
. Large Help subjects are divided into smaller
to make them easier to read.
are small so that the user can look at the program while he is reading the Help.
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.
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
to ask, "How does the Copy command in the Edit menu work?"
Prefer task-oriented Help.
The trend is toward online Help and away from printed documentation. As
interfaces improve and become more standardized, the need for printed documentation decreases. It's been
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
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
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
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
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?
Having exactly the same help online and in the printed documentation isn't helpful.