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 as Training From:Linda Miller <linda_k_miller -at- HOTMAIL -dot- COM> Date:Mon, 2 Mar 1998 07:02:24 PST
I've been trying to develop a relationship between the training dept and
the tech writing dept in our company for some years now. It's been very
difficult for several reasons. Trainers are gone a lot. It's very hard
to tie them down to meetings or commitments. Secondly, no one seems to
know how to mesh our capabilities and products.
The training department I work with takes our tech lit and writes their
own training manuals from them and they end up looking very similar.
That's pretty inefficient. Recently, the training dept. developed a
Windows Help file (which they called the EPSS file [electronic
performance support system]) for a software product that was extremely
similar to the Windows Help file I developed for that product. At that
point, everyone decided that, Yes, maybe we needed to co-ordinate our
efforts a bit more. So, we did manage a few teleconferences where there
was great confusion over how we could really work together. It was
doubly frustrating because we are in different states (IL, MN). What I
was looking for was analysis of the different types of information we
are presenting to the customer and then a divvying up of that
information between us. For my help file, I wanted to be able to jump to
a tutorial that they would provide. The context-sensitive help file
would be the "reference with procedures"; their tutorial would be the
training module for the product. Unfortunately, the software project was
canceled so we again are back at square 1.
We didn't really consider trying to create one file that would fill both
lit and training needs. We did want to create one EPSS that would
fulfill the many needs of our users.
I think many people would like training and tech pubs to work together,
but I don't think many people know how to go about it.
>From techwr-l -at- listserv -dot- okstate -dot- edu Sat Feb 28 12:28:43 1998
>Received: from listserv (188.8.131.52) by listserv.okstate.edu (LSMTP
for Windows NT v1.1a) with SMTP id <0 -dot- 7ED26AF0 -at- listserv -dot- okstate -dot- edu>;
Sat, 28 Feb 1998 14:31:02 -0600
>Date: Sat, 28 Feb 1998 15:27:57 -0500
>Reply-To: Tim Altom <taltom -at- IQUEST -dot- NET>
>Sender: "Technical Writers List; for all Technical Communication
> <TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU>
>From: Tim Altom <taltom -at- IQUEST -dot- NET>
>Subject: WinHelp as Training
>To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
>Got my STC Journal the other day and read the article "Where is the
>Instruction in Online Help Systems?" The author maintains that adding
>instructional design to online help files can help the user.
>It started me thinking about the argument I've had and heard with other
>help designers over the years...should help or paper manuals be seen as
>teaching aids, or as task assistance? Can they be both?
>I'll say at the top that I don't think they can be both, not ideally.
>can, of course, straddle the worlds, but it reduces the effectiveness
>both sides. The article's author, Jean Pratt, makes some good
>but I don't know that she's convinced me that online help should be
>considered in any way to be a training aid. In my view, users don't
>help to learn; they access help to get over a momentary hump. I can see
>putting a tutorial in the help file, but isolated so that it isn't
>For example, Jean suggests that help file development start with five
>points on a checklist, of which the first two are 1) starting with a
>foundation of imperative, task-focused procedures rather than mere
>descriptions of the components of the software (Amen, Jean), but that
>the file should add feedback to confirm the user's actions. Here I
>part company with her. The first is sound task-based help; the second
>verges on instruction. I don't think that most users want or need a
>direction-action-feedback loop to get through a task. It would be nice
>task assistance and learning could be interleaved, giving you two birds
>one pass through the bush, but I don't think they can be easily
>Learning involves redundancy. Task assistance requires speed. Further,
>business deadlines usually negate any effort to create good, clear,
>effective instruction, which takes at least as long to create as task
>assistance, and perhaps longer.
>Still, I'm open to other arguments. Anybody else read the article or
>this discussion? Should paper/online help be a combination of task
>assistance and instruction, or should these two things we kept from an
>Vice President, Simply Written, Inc.
>317.899.5882 (voice) 317.899.5987 (fax)
>Creators of the Clustar Method (TM)
>An out-of-the-box methodology for fast task-based documentation
>that's easy to port to paper, WinHelp, Acrobat, SGML, and other media.