لطفا منتظر باشید ...
Classic Bad Help
Have you ever had this experience? You find an unusual option buried deep in an application, and it piques your curiosity. You hit F1, curious to find out what this option accomplishes. But your optimism dwindles when you read the description provided by the context-sensitive Help system: "To enable option X, click once on the option X check box. To disable option X, click the option X check box again to remove the check mark. Click OK to save your changes."Clearly something is missing here. You want to know what option X does; the Help wants to explain, in oddly explicit detail, how to use a check box. The situation is ridiculous, as the function of option X is not at all obvious, but the way to use a check box is an instinctive part of every computer user's understanding. If you don't know how to use a check box, you probably wouldn't have guessed to press the F1 key for help.This is a classic example of bad help. Some of the characteristics of bad Help include:
It describes the user interface. Users don't need to know how the interface works-they will often discover that by trial and error. They need to know what it does.
It's long. Even HTML Help doesn't have the same bandwidth as a printed document, and endless scrolling is sure to frustrate users.
It uses visual clues. Instructing the user to look at the "top left" or "middle right" may seem logical enough, but with the application running in another (potentially minimized) window, it can cause confusion.
It omits information. Printed documents can afford to choose what they cover. However, Help documents are shipped with the software, and expected to provide a matching reference. Thus, you can't ignore any option or setting that's in the interface.
To understand good help, you need to recognize that most Help is designed to provide reference information. Help really shines compared to a printed book when it's able to use context sensitivity to automatically display a piece of information about a specific window or setting. This is the type of information that all users need occasionally while working with an application they mostly understand.On the other hand, Help is relatively poor at providing tutorial-based learning, which explains tasks that incorporate many different parts. In this case, it's generally easier to use a printed book. Help that tries to provide descriptive task-based learning is generally frustrating for a number of reasons-users can't see the help window at the same time they look at the program window, the help window doesn't provide enough space for the long descriptions that are needed, and most users don't want to read a large amount of information from the computer screen anyway.When creating Help, you should aim to divide it into discrete topics that describe individual windows, complete with all their details. This provides the most useful context-sensitive Help system.
