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:Finding out if anyone rea From:Jerome Yuzyk <jerome -dot- yuzyk -at- FREDDY -dot- SUPERNET -dot- AB -dot- CA> Date:Sat, 23 Jul 1994 13:34:00 -0700
MF> > Does anybody know whether their users read their books? And, for
MF> > do, how do you find out?
MF> > Curious to read replies.
A friend and I were discussing this last night over beers. His firm is
purchasing software that requires attendance at a training course before
the 'key' for the software is granted. Many firms are pursuing this method
in order that their users not besmirch the product's name through their
own neglect of due process (no bitching because you haven't read the docs).
I'm sure many people find it quite amazing that someone will pay several
thousand $$$ for software, slam it on a drive, toss the docs to the side,
and then have the nerve to say the product doesn't work. AutoCad, at
$4000+, is a perfect example of this in my own experience with supporting
So, by Beer 3, we had thought of this notion, which may be extreme, but
good for generating discussion:
Out of the box, the product is no more than a demo, perhaps even a
tutorial. By reading the manual, however, users learn how to enable
specific features of the package in some step-wise fashion, until
some point at which the most important parts of the docs are read,
and the most important parts of the software are enabled. Perhaps
this enabling can be tied to completion of successive stages of a
disk-based tutorial, or even the results of a quiz.
Sounds pretty fascist, I know, and mostly suitable for large packages.
But, it seems to me that something like this would be in the best
interests of a software producer, especially for large, complex
packages, and especially in these days of instant griping via the 'net.
I follow most of the available groups for OS/2, Novell, and the Mac, and
I have to estimate that over half the message traffic generated is due
to the laziness of the user population in these days of instant
gratification a la 100+ channels on TV. Having supported a good several
dozen major apps over my lifetime, I know that the doc writers have
responded very well to the public's gripes about inaccessible
documentation. Unfortunately, users haven't held up their end of the
bargain, and with the net it's all too easy to complain about the
software when it is in fact the laziness of the wetware that is to
blame, as I'm sure most of you know all too well.
Note that this problem extends across technology domains (see the telephony
and Human Factors groups for examples) and education levels. Unfortunately,
the high technology age has led many people to shift the onus of performance
from the human to the machine. Also unfortunately, our educational systems
have exacerbated this problem by relying on technology to educate our
children, and our school systems to provide parenting.
Jerome Yuzyk jerome -dot- yuzyk -at- freddy -dot- supernet -dot- ab -dot- ca
BRIDGE Scientific Services A boy, his girl, and their doodads
* RM 1.3 00857 * Smith & Wesson: the original point-and-click interface