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:On-line v. paper From:Judyth Mermelstein <Judyth_Mermelstein -at- BABYLON -dot- MONTREAL -dot- QC -dot- CA> Date:Sun, 20 Dec 1998 02:24:11 GMT
Darren Barefoot <dbarefoot -at- MPS-CANADA -dot- COM> wrote:
> On-line documentation is a far superior format. No one can argue that
>full-colour graphics, audible instructions and animated screen-shots >aren't
superior to a black and white text.
>Additionally, on-line help can be content and context-sensitive. A
>book always opens in the same place. On-line help can provide faster,
>cheaper, more thorough assistance to the average user.
Sorry, but I would have to disagree. The definition of an "average
user" is probably the source of the problem, and "average user of
what?" runs a close second.
1) Much of the software sold in this world is still being sold to businesses
and individuals who do not rush out to buy a shiny new computer every time a
more powerful model comes out: it's neither necessary nor good economic sense
to do so, since doing so rarely alters the kind of work you need to do or the
basic tools used to do it.
Oddly enough, people find it INFURIATING when the actual software they want
will run perfectly well on their older equipment but the on-line
documentation demands an additional $2000 investment to see the colours and
hear the little voices.
2) Most people who use computers for activities other than game-playing and
surfing have basic literacy skills and use them routinely without needing an
animated screen-shot to show them what happens when they
click on something. They can see it by reading the instruction and clicking
it themselves; in fact, they will learn it more easily from doing themselves
than from watching the animation. Except for certain on-line tutorials for
particular users, these "features" impede learning as much as they help it
--by distracting from the content, by slowing down use of the material, and
by making it harder to skip the portions which aren't particularly useful at
a given moment.
3) A book DOESN'T always open to the same place --unless you don't know how
to use it effectively. Most manuals which are actually used sport a number of
dog-ears or other markers, based on what the user thinks is
most useful --often the index, table of commands, definitions of function
names, and the instructions for an operation that is needed about once a
month but tends to be forgotten between times. Even if you don't use markers,
the book will soon "learn" to open at the most-consulted pages. On the other
hand, context-sensitive documentation opens where the developer wants it to,
4) As others have so ably stated, on-line documentation is NOT available to
you at certain crucial moments. To the comments I've seen I add:
- when deciding whether the product can do what you need and is worth buying;
- when the potential user needs to know it cannot be used along with
other software already owned and happily used;
- when one wants to install the product without overwriting files belonging
to already-installed programs and without installing all
the "extras" one doesn't actually want;
- when one is trying to figure out why the @##$%&^#!! program is crashing on
one's machine or refusing to open.
There is no doubt on-line documentation is cheaper to produce and ship but it
is not necessarily cheaper to use. Aside from the obvious costs of printing
it out, there is a cost in time (and time IS money) involved in not being
able to look things up during the time the computer is tied up with something
or being used by somebody else, in not being able to
train oneself on advanced functions in the lunch-room, and in having to sit
while the voluminous, bells-and-whistles-ridden on-line stuff opens so that
one can look up a command.
There are excellent reasons why programs with poor written documentation have
spawned a whole slew of publishers who print third-party manuals (of varying
degrees of usefulness) which the beleaguered users actually go out and buy.
It really isn't pure cussedness on the part of the user who chortles at the
extra cost the poor software manufacturer must incur to print manuals.
It IS an aberration of the software industry to assume that anything that
increases its profits should be passively accepted by users.
To them I say:
"WAKE UP, GUYS! People buy your products because they believe them to be
useful. Anything you do to make them less useful --harder to install, to
learn or to use-- will cut into your market share, sooner or later, because
your customers are not the fools you take them for. The day may come when
on-line docs have surmounted all of the obstacles mentioned; until then, you
are ADDING VALUE to your product by providing both on-line help and a good
By the way, I AM a staunch advocate of saving trees when at all possible.
That doesn't happen when users end up printing 100 pages of 8-1/2 x 11 to get
a hard copy. Also --in case we'd forgotten-- those CD-ROMs don't grow like
weeds along the roadside: making them and using the equipment needed to make,
ship and play them takes a significant toll on resources, too, and
NON-RENEWABLE resources at that!
Yours for ecological AND social sanity,
<judyth_mermelstein -at- babylon -dot- montreal -dot- qc -dot- ca>