TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: WinHELP Philosophy From:"Susan W. Gallagher" <sgallagher -at- EXPERSOFT -dot- COM> Date:Tue, 30 Jan 1996 14:03:23 -0800
David_Dubin wrote:
>We are in the middle of developing Help for an in-house application and I have
>a question of those of you who have gone this route before. Simply, what do you
>feel that Help is, and what should one include in Help files?
>I have been taught (and believe) that Windows Help should not take the place of
>a user's manual and should not become simply an electronic version of the
>user's manual. Help is (or should be) that information a user needs immediately
>to solve a problem. Help is driven by topics (info chunks) and, since the
>WinHelp environment is interactive, the user can navigate to the depth of
>knowledge that is necessary to complete that task. Help is not a lineal
>environment, as a user's manual is, even an electronic user's manual.
You're right on, David. Help is there to provide "information on demand"
or "just-in-time learning". When the user access context-sensitive help
from a dialog box, they have a question in mind, usually "What is this
(dialog box/field)?" They need to know what information the program is
asking for. Your job, as the help author, is to anticipate the user's
question and answer it as succinctly as possible.
>Our philosophy is that most users who are stumped in an app will go directly to
>the Search button and look for information about the concept that they need,
>before they go to a Contents section or even a How To... section.
Yup, context-sensitive first, then search. Browse last and only if
what they're looking for hasn't appeard yet. A friend of mine on
utest does a lot of studies that involve online help. He says the
average user accesses online help for a minute or less at a time.
Not a lot of time to digest concepts, but plenty of time to find
out that the program wants time in a 24-hour format or that your
user name should match the name your e-mail post office uses.
(Since some think that "Hope this helps" is overused, I won't
say it, but I do.)
-Sue Gallagher
sgallagher -at- expersoft -dot- com
