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.
I think my message, posted yesterday to the list, answers some of your
concerns.
To elaborate a tiny bit, from an economic standpoint, Help on Help is a
small expense for a potential payback in customer satisfaction and in
avoiding a support call. Even one call costs money (there's info in the
TECHWR-L archives about how much). Users who can't find the information
online often pick up the phone. Help empowers users to solve their own
problems, but because help systems sometimes differ (they're not all WinHelp
or HTML-based Help), users have to know or discover how to use the Help. Of
course, it's hard to tell when a support call (or anything else) has been
"prevented," but that's not an argument for not attempting the prevention.
Help on Help doesn't really complicate the Help system. It's really just
another topic.
The argument that you have to know how to use the help system in order to
get Help on Help has some validity, but I've watched users click on the Help
menu on the tool bar and get very frustrated. If the first item is something
like "How to use this Help system," at least they have a guide.
If you have a more elaborate help system, it makes sense to tell people how
to use it. Steve Krug wasn't kidding when he titled his book _Don't Make Me
Think_. And, as someone else on the list pointed out, you can't really go
wrong underestimating your audience. Our users don't want to spend time
figuring out our interface, and the easier we make it for them to navigate
through the interface, including the Help system, the better.
Just my $0.02.
Marguerite
-----Original Message-----
From: Marguerite Krupp [mailto:mkrupp -at- cisco -dot- com]
Sent: Monday, December 02, 2002 1:56 PM
Jan Henning wrote:
> I wonder about that. I certainly do not doubt your account or that it
> is typical. But are people who do not have the patience to closely look
> at the interface going to read documentation about documentation?
>
> My personal experience indicates otherwise. But maybe that is atypical?
.........................
Maybe, but it's an easy hole to plug, and if it heads off a support call,
it's worth it.
In one product for a major manufacturer, there were THREE different Help
buttons, each of which took you to a different place. Lousy design, yes, but
we had to write around it.
As with anything else, if you know WHERE to look, finding the answer is
obvious. If you don't (and some interfaces are not at all intuitive), it
really "helps" to have "Help on Help."
Marguerite
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Check out SnagIt - The Screen Capture Standard!
Download a free 30-day trial from http://www.techsmith.com/rdr/txt/twr
Find out what all the other tech writers, including Dan, already know!
Order RoboHelp X3 in December and receive $100 mail in rebate, FREE WebHelp
Merge Module and the new RoboPDF - add powerful PDF output functionality
to RoboHelp X3. Order online today at http://www.ehelp.com/techwr-l
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
