Re: Help as Training

Subject: Re: Help as Training
From: Tim Altom <taltom -at- IQUEST -dot- NET>
Date: Mon, 20 Apr 1998 17:20:18 -0400

This sounds like as good a compromise as it gets when using help for
training.

My original premise might have needed some explanation, I suppose. My point
was that you can either assist the user, or you can train him, but you can't
do both outstandingly well at once. Training is linear and cumulative.
Assistance is randomly accessed and task-specific. Training should
incorporate copious explanation. Assistance requires little or none.
Training should have lots of feedback and be extraordinarily fault tolerant.
Assistance requires very little feedback (barring special cases like
training cards) and can be highly fault intolerant. Assistance focuses only
on getting the user through this fishing expedition. Training focuses on the
process of fishing. Assistance is emergency fallback material. Training is
skills acquisition.

Now, it sounds like this arrangement separates topics designed for training
from topics designed for assistance. That seems as though it might work,
although without macros, DLLs, or training cards/developer assistance it's
hard to see how straight WinWord would be able to provide top-notch training
feedback. But at least the two worlds aren't confused.


Tim Altom
Simply Written, Inc.
317.899.5882
http://www.simplywritten.com
Creators of the Clustar Method for task-based documentation

>
>Preface, I work for a large financial services company, and the majority
>of our systems are developed for use by employees, so we can keep very
>careful track of how things are being used. Our biggest problem is that
>none of our employees were using help systems. Not the ones we shed blood,
>sweat, and tears developing and not the ones developed by third party
>software vendors (Microsoft Excel, for example).
>
>We also tend to have extensive classroom training for key software
>roll outs. They are expensive for software roll outs, but prohibitive
>for new employees that are added to offices in ones or twos. One of
>the solutions that we've tried very successfully is to use Help as the
>vehicle of the classroom training. A separate tutorial is included with
>the normal help file, and, where appropriate, the topics from help
>are used as the topics of the training or to provide additional
>material.
>
>The advantages of this are many. Because the trainees are familiar with
>the kind of information that is available in the help file once they
>have completed training, they have a tendency to consult it more
>frequently once the training is over.
>
>The training material is always present with the software for new
>employees. It's on the Help menu. The training material is always up-
>to-date because new versions of the software install new versions of
>the training.
>
>We would have been employing a professional trainer to develop the
>training material _and_ a technical writer to develop the Help and
>user documentation anyway. Having them work together to reduce the
>amount of overlap in the material is natural.
>
>We use the help browse sequence for the tutorial information. The
>user fires up the software and the help file and goes through the
>tutorial either as a self-paced study aid or at the direction of
>an instructor or, in at least one case, as self-paced study with
>the trainer circulating to provide additional information as needed.
>
>We've been very pleased with the results. I don't know if this
>qualifies as what Tim was talking about.
>
>
> _______________ _____
> / ___ __/__\ \ / / _\ Steve Fouts stefou -at- eskimo -dot- com
> /___ \| | ___\ | / __\ "You must not mind me, madam;
> / / \ | \ / \ I say strange things, but I
>/_______/__|_______\_/________\ mean no harm." --Samuel Johnson
>
>
>
>




Previous by Author: SCO doc web site
Next by Author: Re: Knowledge versus Information
Previous by Thread: Re: Help as Training
Next by Thread: URGENT: Company Policies


What this post helpful? Share it with friends and colleagues:


Sponsored Ads