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: Opinions on Embedded Help? From:Bill Burns <BillDB -at- ILE -dot- COM> Date:Tue, 9 Mar 1999 09:09:38 -0700
David writes:
> Should we give users an option to turn off embedded help, or should we
> keep
> it always there so that it's always giving them different things to read?
> At the WinWriters Conference, one presenter put it this way (paraphrased):
>
> "You can lead a horse to water, but you can't make it drink...
> ...but you *can* dunk its head under water and kick it up the backside!"
>
Was this Cheri Zubak's presentation? I saw it at the Help Technology Update
in September. In any case, I like the concept of embedded help systems, but
I ALWAYS think the user should have options. It's simple enough to provide.
Set the application defaults to open the help automatically, and provide
users with the means to close the help window if they wish. In addition,
allow them to set defaults for the initial application state. If they don't
want the help window to open when the application starts, they can change a
setting in an options dialog somewhere.
Depending on the implementation, an embedded help system be relatively
unintrusive. Nonetheless, some people want that extra screen real estate
more than they want the help. So let them control their destiny.
Bill Burns - Eccentric Technology Consultant
ILE Communications Group
billdb -at- ile -dot- com
Call me fishmeal.