How to Find Problems

In the following sections, I'll list problems to check for while you are reviewing documentation. If you don't personally check all of these items, make sure that someone checks the items you don't.

General

  • Is the Help accurate? Is it complete?
  • Is the Help consistent? Does it use terminology consistently? Does the terminology used in the Help match the program?
  • Is the Help helpful? When you have a question about the program, does the Help answer it? Does the Help spend too much time describing the obvious? Does it describe the program details well?
  • Are the Help topics an appropriate size? Do you find them too long? Are they easy to read? Do you have to do a lot of scrolling?
  • Is the Help window conveniently sized and located? Can you work with the program while viewing the Help?
  • Is the Help easy to access? Try to find help using the Help button and the F1 key. If supported, try to find help using the What's This? button or the Shift+F1 key. Try to find help using the Contents, Index, and Find tabs of the Help Topics browser dialog box.
  • Are the step-by-step instructions accurate? Beginning users are especially disturbed when following instructions that say something is on the screen (either through a screen shot or text) when it isn't. This makes the user think that he either doesn't understand what is going on or that he has made a mistake. Any likely discrepancies should be noted in the text. Have a beginning user review all instruction-based help and documentation and make sure that the user can accurately reproduce all the steps described with the program.

Details

  • Does the Help explain one way to accomplish a task or several ways? To keep the text simple, the Help should describe a single, standard way to accomplish a task. For example, if you can accomplish a task by using the menu bar, context menu, or keyboard, just explain the menu bar approach.
  • Do all the windows have context-sensitive Help? Do all the dialog boxes? Is the right Help context always used? Do static text controls such as group boxes, static rectangles, lines, bitmaps, and icons have Help contexts when they shouldn't? Do the labels of disabled controls have the correct Help context? Note that the labels of disabled controls require special handling and are likely to have the wrong Help context.
  • Does the Help contain screen shots? Are those screen shots really necessary? Are they helpful?
  • Do the indices use plural forms of nouns? For example, there should be an entry for dialog boxes, not dialog box. Are the terms indexed in all the variations that a user is likely to look for them? For example, a Compile tab of an Options dialog box should be indexed as Compile tab; Options dialog box, Compile tab; and dialog boxes, Options, Compile tab. Do different level users use different terms? If so, make sure the Help indexes the terms used at all levels.
  • Are hyperlinks used effectively? Do the hyperlink topics present relevant information?
  • Is the spelling correct? Don't assume that using a spelling checker means that the Help does not have spelling errors.


Developing User Interfaces for Microsoft Windows
Developing User Interfaces for Microsoft Windows
ISBN: 0735605866
EAN: 2147483647
Year: 2005
Pages: 334

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net