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.
"S. R. Begnoche" wrote:
>
> At 10:30 AM 3/29/00 -0800, Becca Price wrote:
> >We're going to be developing computer-based training
> >for the software I'm documenting... and I really don't
> >know where to start.
Not what you asked for, but one thing to think about is
to what extent the application itself can train users
via good data validation, clear feedback, ...
For example, years ago I documented a mainframe software
system that handled table data in memory (shameless plug: http://www.dkl.com) and had an editor with it, based on
form-like screens and data entry into fields. One feature
was cross-field validation, checking (usually via table
look-up) whether data in two or more fields match.
For example, you could allow a user to type in either the
full name of a state in one field or the two-letter code
in a different field. Hit 'enter' and the two would be
checked for consistency and, if only one was present,
the other automatically filled in.
One of our customers was hugely pleased with the training
effects of that. New users could type in the names and be
told codes, or try codes and see the results. From what
they said, this was the best solution they'd found to a
problem they'd had for years and that neither training nor
handy reference charts from the doc dep't had solved.
Of course it wasn't just state codes. Part numbers and
descriptions, name and job title, ... everything worked
that way in their application.
We certainly hadn't designed our system with this in mind,
and their application programmers quite likely hadn't
thought of it either. We'd just built in a necessary feature
and the programmers had used it to do sensible data
validation. The only unusual thing they'd done was to
provide the use with clearer feedback than many software
systems do.
Methinks a look at your software design with this notion
in mind might turn up some possibilities.