On-line Help: Are We Tossing the Users a Life Saver or an Anchor? A. Brady Farrand and Susan J. Wolfe Tandem Computers 10300 North Tantau Avenue, Loc 55-54 Cupertino, CA 95014-0725 farrand_brady@ tandem.corn (408) 285-2769 wolfe susan@ tandem.tom (408) 285-2650 Current Approaches to On-line Help On-line Help is a necessary part of today's software applications. The challenge of creating an effective online Help system faces most every development team. Unfortunately, the users and the developers frequently differ in their opinions about the usefulness of the on-line Help information. The goals and the guidelines given to the development team say that the user with a question needs: (1) Answers. On-line help should provide the information necessary to answer any user's question (2) Access to answers. On-line help should provide easy ways to get at the information (e.g., pull-down menus of help topics, indexes of information topics, function keys for. specific help topics, hypertext links to relevant explanations). What these goals and guidelines fail to emphasize is how liule this information is used, because it is so hard to know the question, much less navigate to the answer and comprehend it. Context-sensitive Help addresses these issues. The user may not need to step back and formulate a question. Access to the answer can be found with a single keystroke. A study investigated the real use of context-sensitive Help. An Experimental Evaluation of Context-sensitive Help Eight subjects performed different tasks in an experimental evaluation of Help. These users would not perform even the minimal cognitive tasks necessary to take advantage of the context-sensitive Help: ¢ They resisted using Help. They preferred to test and explore the application. Even when they needed a simple fact (e.g., legal responses to be entered in a field) they chose to test and explore rather than use contextsensitive Help. ¢ They only looked at the first page of the Help. When they did access it they would look at the displayed text. If they did not spot the answer there they would quit Help rather than scroll to read the rest of the Help text. ¢ They scanned for keywords, they did not read for understanding. When they looked at the Help text they would scan for a word they believed key to their problem. They did not digest the Help text; they did not understand its explanation. ¢ They often became confused over whether they were currently in the application or in Help. They even attempted to perform the recommended action before quitting out of the Help screen. Guidelines for Context.sensitive Help The development team can provide both a n s w e r s and access to answers, and still fall. This experiment showed that even "context-sensitive Help" did not solve the problems. The users reluctantly used the contextsensitive Help, seldom read the text, and never searched for a synonym of the keyword. Taking advantage of long, fully explanatory, contextsensitive Help text can require mentally "switching gears." This is a difficult cognitive task, changing from "see and understand what happens" mode into "read, interpret, build a mental model, and analyze" mode. This is why the users search for keywords- it takes less mental effort, they d o not have to fully switch gears. This is why they only look at the first page, they avoid the work of a long-term commitment to analysis mode. This is why they become confused about whether they are in Help or in the application. They do not fully comprehend the switch to another mode. This is why they avoid on-line Help whenever possible. The participants only want to use on-line Help when it provides a quick, sure route to the needed information. The context-sensitive nature of this on-line Help is its great advantage. When the call for Help provides the right information (e.g., when it shows the acceptable time formats) which immediately jumps out at the user, onfine Help is a godsend. But it is the brevity of this context-sensitive Help that makes it work. The right information must not be obscured by other information. This suggests that context-sensitive Help information must be brief. But some topics are not and can not be brief. Tasks can require several displays. Windows and screens often include many different fields. We need to learn to break up complex objects into simple objects that can support brief, context-sensitive Help. We need to decide whether complex tasks should be covered in on-line Help. To the drowning user, poorly designed online Help can be an iron anchor rather than a buoyant life saver.

/lp/association-for-computing-machinery/on-line-help-are-we-tossing-the-users-a-life-saver-or-an-anchor-UFrfJItd7l