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.
> The writers (Torkzadeh and Doll) include "end-user tool manuals"
> as one component of user support in an end-user computing
> environment. But they do not define an end-user tool manual.
> My question: What's an end-user tool manual? How is it
> distinguished from application oriented documentation?
> Can someone on this list enlighten me? Thanks.
This is interesting, since we are making distinctions in products around
here (for purposes of the doc) using this sort of a paradigm.
My guess is that Torkzadeh and Doll are referring to software products
designed to let you build tools for another set of users. These are
tools that are very specific to a task or categories of tasks.
The end-user manual addresses, for example, how to use a particular
interface to write the results of clinical trials to a database and
initiate a series of reports or graphs using that data. The application
oriented documentation explains how to build the interface and attach
the programs that crunch the numbers and produce the charts and graphs.
Consider the difference in the manuals by thinking about the segments of
your audience each one addresses. WARNING: Here comes a metaphor.
If your audience wants to drive a car, they can get by with an
explanation of things like "steering wheel", "gas pedal", and "brake".
These are your end-users. They get the operator's manual - the end-user
documentation.
To fix a car, they need to learn the meanings for "wrench" and
"crankcase" before they can get very far. They are your application
programmers. They get the parts list and the specs - the application
oriented documentation - the reference doc and intermediate usage
material.
A few of your users will want to design their own cars. These folks will
be system administrators, database administrators, or systems analysts.
They get the systems design stuff (if you hav any), the file specs, and
so on.
This is all my own theory (sort of, at least applied to doc). The
original car metaphor came from Jan Steinman in a post to an OODBMS
newsgroup on USENET in a completely different context. However, I fell
in love with it and have been using it to clarify my own audience
definitions ever since.
Anybody have anything to add? Anybody have a different way of looking
at this? I'm really interested in this topic.
|Len Olszewski, Technical Writer | "Hardcopy is the ultimate backup!" |
|saslpo -at- unx -dot- sas -dot- com|Cary, NC, USA| -John Sanders |
|---------------------------------------------------------------------|
| Opinions this ludicrous are mine. Reasonable opinions will cost you.|
