Reactive Assistance Mechanisms
Reactive assistance mechanisms, unlike the passive mechanisms we've been discussing, are displayed only as a response to some action by a user. Intermediate or advanced users are more likely to use reactive mechanisms than beginners, who might not know how to invoke them or even that they exist. For this reason, they're not particularly good mechanisms for the kind of "what's this all about, then?" assistance that beginning users require.
Most reactive assistance is provided as some form of online help. Several paradigms for providing this type of online assistance exist, and we'll look at two in this section: traditional online help and the newer What's This tips. Although not often considered in that light, error messages are also a kind of reactive assistance, and we'll look at them at the end of this section.
Traditional on-line help is essentially a transfer of printed documentation to the computer, and as almost always happens when a real-world object or activity gets computerized, this transfer makes some things easier and some things harder.
On-line help is more accessible than printed documentation, and the ability to display cross-referenced material with the click of a mouse is certainly a benefit. On the other hand, on-line help is a lot more difficult to browse, and you can't take it with you to the lunchroom when you go to get a cup of coffee.
Careful design of the help system can go some way toward ameliorating the disadvantages of on-line help. (It's still only as portable as the computer is, however.) Designing and writing help systems is a huge topic, most of which lies outside the scope of this book. All I can do here is give you some general guidelines, point out a few peculiarities of writing help for database systems, and refer you to the Bibliography for more detailed information.
The first and most important consideration when designing on-line help for your system is that no matter how tightly linked the help might be to your system, you should never consider it an integral part of the user interface. That is, your system must be able to stand on its own and never force users to resort to on-line help (or any other documentation, for that matter) to complete a task.
Remember that beginning users might not understand what on-line help contains, so they might not think to press F1 when they get confused. You should consider on-line help as a support for the user assistance provided within the system itself, not as a replacement for it. It's all too common for designers to think that having an on-line help system relieves them of the burden of making the system self-explanatory. In my experience this is a mistake and leads to ugly, unusable software.
The second consideration when designing on-line help is what type of support you want it to provide. On-line help topics can be roughly divided into two types: task-oriented and function-oriented. Task-oriented topics tell users how to complete a specific task, such as how to print an invoice or schedule a meeting. Function-oriented topics provide detailed information regarding a specific function (such as the Print command on the File menu) or control (the CustomerID text box on a form). The two types correspond roughly to Users Guides and Reference Manuals in printed documentation.
Both task-oriented and function-oriented help have a role in supporting database systems. If your system supports many work processes, or if the work processes it supports are complex, task-oriented help can be of considerable assistance to users by providing a kind of roadmap to the procedures. It's still important to provide support and guidance within the system itself, though. It's not acceptable to merely present users with an alphabetical list of forms like the one in the Access Database window and rely on on-line help to tell them in which order the forms must be completed. (Well, it's not acceptable if you're working for me, anyway.)
Ideally, task-oriented topics should not include conceptual or introductory material. Remember, this isn't the right tool for teaching your users what the system does. The only purpose of task-oriented help topics is to provide a summary of the "how" of a procedure, not to explain the "what" or the "why."
Using multiple help topics for complex subjects will keep the topics readable on the computer screen. If the work process being explained is complex and has multiple paths, it's best not to try to explain all paths in a single topic. Just explain the simplest or most usual path in the main topic and provide links to topics explaining the variations.
Whereas task-oriented topics concentrate on the "how" of using your system, function-oriented topics concentrate on the "what" and the "why." For database systems, most function-oriented topics will refer to data items and controls rather than functions per se. Few database systems will require topics such as those provided by Access help, for example, where it's necessary to explain the precise syntax of the Mid$ function.
Systems do require topics that explain the meaning of every entity and attribute in the system and the constraints that pertain to each of them. They might also require topics to explain the use of various control types used by the systemhow to navigate through a tree view control, for example, or how to pick a date using a calendar control.
In planning these data-oriented topics, it's important to think about why users would ask for help. If a user is looking at an Orders form text box with the caption "Desired Delivery Date," it's really extraordinarily unlikely he would press the F1 key because he doesn't understand that this is the date the customer would like the goods delivered. If this is all that your topic tells users, it's worse than uselessit's an irritating waste of time.
So why might the user have pressed F1? Maybe he doesn't understand why the date is already filled inso explain the default and how to override it. Or maybe the customer has told him to have the goods delivered "any time after the first of the month"so explain that he should enter the earliest date or whatever rule applies in your environment. The better you are at thinking about the questions users might really be asking, the more effective your help system will be.
What's This? Tips
What's This? tips are much like task-oriented on-line help except for how they are invoked. What's This? tips are invoked by clicking the question mark icon in the window's title bar and then clicking a control within the window. Figure 21-5 shows the What's This? topic for the Windows In Taskbar check box in the Options dialog box in Access 2000.
Figure 21-5. What's This? Tips Are Displayed in Dialog Boxes by Clicking the Question Mark Button in the Title Bar and Clicking a Control
I like the idea of What's This? tips a lot because they are so tightly integrated with the user interface of the system. I've seen novice users stumble upon What's This? tips on several occasions. I've never seen novice users find on-line help by pressing F1 by accident, and I imagine it might be a little scary if they did, what with strange windows opening up all over the place.
For simple systems, a good set of What's This? topics might be all the help you need to provide, particularly if the system doesn't support a lot of complex work processes. What's This? topics must be fairly short, however, since they're displayed on top of the associated window and can't be scrolled. If you need to explain complex constraints, you simply won't have the space and you'll need to back up the What's This? topic with one or more longer on-line help topics. (Be sure to add "Press F1 for more details" or words to that effect to the end of the What's This? topic.)
The specific question a What's This? topic attempts to answer isas you've probably guessed from the name"What is this thing?" Think of a What's This? tip as a paragraph-long control caption. Because of space constraints, you usually can't be highly creative in responding to the questions you think users might be asking. But with a little thought, you can do better than just providing a reworded control label.
Describing the Desired Delivery Date as "the date on which the customer desires delivery of the goods" is just as evil in What's This? tips as it is in on-line help. At the very least, try saying "the earliest date on which the goods are to be delivered. This value defaults to three days after the order date, but you can change this value by clicking the field and typing a new date. Press F1 for more details."
Audible feedbackusing a computer tone to describe some system stateis an extremely powerful mechanism for assisting users, but designers can use its power for good or evil. The "Beep, you blew it" dialog box that's displayed when the system detects a "user error" is a prime example of using audible feedback for evil purposes. Users do not enjoy having attention drawn to their mistakes, and a beep not only draws a user's attention to the problem, it also notifies anyone within earshot. Besides, the default beep is a really annoying sound.
Turn audible feedback on its head, however, and it can be a wonderful tool. Instead of having the system blow a computer raspberry at a user when it gets confused, try having the computer emit a soft sound (I think of it as a purr) when something goes right. Say that during data entry the system is checking each field as the user exits the corresponding control. If the data complies with all relevant constraints, the system can issue a soft "I'm OK" sound. (The sound shouldn't be very loud.) If any problems occur, the system makes no sound but instead displays a message in the status bar. Silence is sufficient notification of the problem, and the user will check the screen.
The best analogy for this positive feedback technique (for which I am indebted to Alan Cooper) is the keyboard. As you press each key, the keyboard makes a soft click. You're probably not consciously aware of the sound, but if it were to stop, you'd notice it immediately and investigate the problem.
The example of the keyboard ought to calm any fears you might have regarding the cacophony of a room full of data entry operators. As I've said, the "I'm OK" sound needn't be obtrusive to be effective. I've successfully used positive audible feedback in a system designed for a call center with over 100 users in a single room.
Most people don't consider error messages as a means of providing assistance to users, which is a pity. But then, most error messages don't assist users, they chastise instead, which is an even greater pity. Instead of treating error messages as an opportunity to point out users' faults, treat them instead as a plea for users' assistance. The system has got itself into trouble, and it needs user help in getting out.
A well-behaved person, when requesting another's assistance, doesn't make cryptic statements or issue demands. A well-behaved person doesn't try to imply that it's someone else's fault that she is confused or in trouble. A well-behaved person explains a problem as clearly as possible, requests assistance politely, tries not to impose any more than necessary, and takes pains to explain the implications of her requests.
A well-behaved computer system ought to do no less. In fact, because computer systems are deserving of less respect than people, they ought to do more. (Groveling is not inappropriate here.) When issuing "error" messages, the system has an obligation to:
The system will sometimes get itself hopelessly confused, or some environmental factor such as a shortage of memory or a disk failure will at times make it impossible for the system to continue operation without assistance from the user. When these events occur, you have little choice but to display a message to the user. This is a wonderful opportunity not only to get the assistance the system needs, but also to provide the user with the information she needs to help the system stay out of trouble in the future.
By explaining the situation clearly and not using confusing jargon, the message you display to users will allow them to resolve the problem right away. Having understood the problem the first time, a user will be in a position to avoid having the same problem in the futureassuming the situation is avoidable. Invalid data entry formats are avoidable; hard disk failures generally aren't.
By explaining the implications of users' choices, the system is far more likely to receive the most sensible response. Remember that a lot of things that seem perfectly obvious to you won't be obvious to the user. Don't talk down, of course, but don't be afraid of stating the obvious.
Wording the message politely and not imposing on users are just good manners. Remember when your mother told you that you'd catch more flies with honey than you would with vinegar? If users perceive your system as generally polite and helpful, they'll be inclined to forgive that one weird GPF that you never were able to track down. (Nobody's perfect.)