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:Re: Reading the Manuals From:Rose Wilcox <RWILC -at- FAST -dot- DOT -dot- STATE -dot- AZ -dot- US> Date:Mon, 17 Apr 1995 15:22:00 PDT
Robert, I apologize in advance for snipping and quoting your
message backwards, as I want to reply to your points in
a backwards order....
>For example, I have yet to find ANYONE besides me who has ever even
>noticed Microsoft Word's "Style Sheet" feature. Nor do they understand
>automatic numbering. Many indent paragraphs by typing three or five
>spaces, and even center lines by spacing to the middle of the page.
>They use whatever the default font is, exclusively.
I learned most of what I know about these features *without* reading the
I learned how to do these by playing with the features. I turn to manuals
references when my playing/experimenting results in a dead end. Sometimes I
find out where I went wrong, and sometimes I find that what I was trying to
was impossible. Sometimes with Word, I find the information I need in the
and sometimes I find the information I need in the manual, and sometimes the
information I need is not written down, but is known only to some kind soul
this list who experimented, also....
>But people who don't read the manuals, like self-taught people everywhere,
>don't know what they don't know.
This is a good point. I do find it helpful to read the Table of Contents
index of a manual and look up things I never head of.... Sometimes it
me the terminology the developers and tech writers used (as opposed to
the terms I think in), and sometimes it teaches me a new feature....
>Setting aside the question of why we're all busting a gut to write
>quality documentation when many of us take pride in never reading any,
>I must admit that most people I've worked at feel the same way.
Well, I don't take pride in not reading the documentation, even though I
work that way. I think the reason I learn that way is that when I first
using computers in about 1980, the vast majority of documentation was bad.
(In fact, that's why I decided to *become* a technical writer... but that's
Nowadays, the documentation has improved, but the quality still varies.
MS Word doc isn't *bad* per se, but it is true that some stuff is in the
and some is in the manual, and you kinda have to fish around to find it, so
if you can guess without looking, you may save yourself a little time.... I
however, embarrassed by my tendency to not read doc, and I tend to joke
around about it. But because of my affliction, I make it a point to try to
and organize my documentation for all my readers -- including the types who
read every word I write and the types who use the documents and on-line
help when they get stuck.... I think that understanding of different
needs helps to make higher quality, more usable documentation.
rwilc -at- fast -dot- dot -dot- state -dot- az -dot- us
ncrowe -at- primenet -dot- com
"The more articulate you are, the more dangerous words become."