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.
Marge Faber reports: <<Our department recently developed an in-house
software application that is available to and widely used by other
departments in the company. However, when training was offered to the other
departments, many chose to ignore it and the tech writer who was originally
involved in the training and who developed the on-line now help gets many
calls for "How do I. . .?">>
I wonder what the training equivalent of RTFM would be: ATFT? <g> One
obvious solution is for the writer-trainer's manager to put their foot down:
"You didn't attend the training, and now you expect me to devote my staff's
time to compensate for your pointy hair? I don't think so." Well, express it
a tad more diplomatically perhaps <g>: "We'd be happy to offer formal
training at a time of your convenience, or set up a help desk that's open an
hour per day--you pick the hour--but you can't simply call our writers any
time you choose. They have work to do for me."
<<The on-line help is thorough and well presented, but many people prefer to
be walked or talked through the typical tasks for the first time. To
minimize the time the tech writer spends on the phone and to make training
available to users at any time, we are considering developing
demonstrations... That way users could see/hear an explanation of the task
they need to do.>>
The problem with demonstrations is twofold: First, they are passive and
don't engage the viewer, which means that they're ineffective teaching tools
for a large group of students. Second, they probably take about as much time
to develop as a wizard, and a wizard is likely to be far more effective.
Among other things, the person "learns by doing", even if someone is holding
their hand while they do, and the wizard is available even when your support
staff isn't. Third (okay, "twofold" for very large values of two <g>), it
lets the user avoid using the documentation, which is never a good thing.
"Teach a user to fish..."
Of course, you should also be paying close attention to the types of calls
for help you're getting. Repeated calls concerning the same software feature
are a strong suggestion that the interface isn't nearly as logical as the
designers thought. And perhaps the documentation isn't nearly as thorough
and well-presented as you believe? Documentation that we consider fine often
fails the "user test" simply because the users aren't us; in fact, they may
have very different needs.
--Geoff Hart, geoff-h -at- mtl -dot- feric -dot- ca
(try ghart -at- videotron -dot- ca if you get no response)
Forest Engineering Research Institute of Canada
580 boul. St-Jean
Pointe-Claire, Que., H9R 3J9 Canada
"Wisdom is one of the few things that look bigger the further away it
is."--Terry Pratchett
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or view a live demo at: http://www.ehelp.com/techwr-l3
---
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.
