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.
Christine Anameier is revising a WebHelp system <<... that is mostly what I
think of as "guided tour" online help: big screen captures from the
application that you click on if you want to know what a particular
interface element does.>>
I call that "reference" help, and find it very useful for various tasks,
such as identifying what an obscure icon does or what a field name means.
But it's rarely sufficient by itself. I'm not familiar with WebHelp's
features, but this is the kind of thing that's ideally suited to "tool tips"
in WinHelp. If there's a WebHelp equivalent, that's where this information
belongs. Why? Because then the information is immediately available via the
interface, without forcing the user to open the Help file and search for the
information.
<<My own inclination ("overwhelming urge" might be more accurate) is to
revise the help radically and focus it on user tasks.>>
Good idea, particularly if the reference material can also be preserved
without interfering with the task information. But don't forget, "focus"
means "concentrate on", not "eliminate all else".
<<If I do this, I see two options for the "click to see what this button
here does" sort of material: (1) Remove it entirely. (2) Put it in topics
separate from the task-based topics, and link to it.>>
I'd go with the second option. It rarely hurts to have additional
information available (provided that you don't bury the really important
stuff so deep in the reference material that nobody can find it), but it can
certainly hurt if the information isn't there when someone needs it. Plus,
you're less likely to step on the toes of whoever recommended creating the
current help spec to begin with. I note from your @ddress that you're
working for Seagate, and that's a big enough company that there are probably
toes aplenty to step upon. Politics rears its ugly head everywhere!
<<my impression has been that users turn to online help when they're in the
middle of doing something and they run into trouble. I think the question in
their minds is going to be "How do I _______" rather than "What is the Name
field for?">>
Yes and no. "How do I..." often relies on explaining what to do with a list
of fields, checkboxes, etc. I often find that the overall procedure is
familiar to me, but I need to figure out what a particular visual glitch
("icon", if you prefer) or field represents; if I know that, I can fudge my
way through the rest of the procedure without having to read the rest of the
help. And from anecdotal evidence, that's what most users do anyway: try to
figure things out without referring to the documentation, then consult the
docs only when they fail. My biggest objection to the vast majority of help
systems that I've used is that it's impossible to find the help topic that
addresses the problem I just encountered; I doubt I'm the only one who has
this trouble. In my opinion, the ideal user interface is one in which users
never have to open a help file: by binding the help more closely to the
individual fields, dialogs, and error messages, the help is immediately
available without having to search at all. Now _that's_ context-sensitive
help!
--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca
"User's advocate" online monthly at
www.raycomm.com/techwhirl/usersadvocate.html
"The most likely way for the world to be destroyed, most experts agree, is
by accident. That's where we come in; we're computer professionals. We cause
accidents."-- Nathaniel Borenstein
IPCC 01, the IEEE International Professional Communication Conference,
October 24-27, 2001 at historic La Fonda in Santa Fe, New Mexico, USA.
CALL FOR PAPERS OPEN UNTIL MARCH 15. http://ieeepcs.org/2001/
---
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.
