Mea Culpa, All Ye Dummies

[Moshe Koenig <alsacien -at- NETVISION -dot- NET -dot- IL>]

The discussion about "dummies" is a topic that has gotten a lot of
attention from a lot of technical communicators, and rightly so.
The problem is that the term "dummy" can be an insult, even though
there are plenty of people who rush to buy the "for Dummies" series.
The reason is partly historical; prior to the advent of the graphic
user interface (GUI for those who prefer the computerese term),
working with a computer meant that you had to run to your bespectacled
neighbor's kid named Edgar for assistance. DOS commands made Latin
verbs look like child's play, and the user had to know everything
by heart or else. The graphic interface reduced the intimidating
element of computers, but some people feel helpless in front of
a machine that seems to have a mind of its own, when it really doesn't.
Many people, on the other hand, are really very bright, but they
don't have time to invest in learning. The "for Dummies" series
offers a promise of a comfortable learning curve -- sometimes.

However, as Rebecca Phillips said, the buddy-buddy Micro$oft style
can seem condescending and distracting. (I caught that dollar sign,
Rebecca -- bravo!) I remember on a recent job interview when the
manager of the department mentioned one of his pet peeves: the
old Lanier user manual, when it said, "Now, let's get you comfortable."
As he retorted, "I'd expect to hear that from a nurse!" Remarks of
this nature can lead a person away from the point very easily.

As many of you have read on this forum, I've been with a project
for over a year now that was supposed to have ended last November.
It is the project that seems to be the Story Without End, and it
is VERY relevant to this discussion. The product, called easyBASE,
calls itself "the database for dummies," and all the promos
revolve around this theme. Basically, however, the product isn't
for dummies at all; the people who would typically use the product
are business people who want database facilities without having
to learn relational database programming. When I was asked to
document the product, I was told to keep in mind that the user
was not necessarily sophisticated or computer-literate, but even
worse, I would encounter many former users of relational database
tools who gave up. That said, I had to write documentation that
injected an element of humor and kept the mood from seeming too
grim as I explained how to create a database, how to structure it,
and how to customize a screen form. In other words, I had to make
something sound simple that was anything but simple.

First of all, I avoided phrases like "I've prattled on about ..." or
"It isn't a good idea to..." I took considerable liberties along the
way, but one thing I did NOT do: I did not ever speak to the reader
as if he/she were some brain-dead jerk coming to sit at my feet to
learn. If anything, I tried to emphasize the positive, to assure the
novice user that he/she WOULD succeed and would be amazed at how
quickly he/she could learn to use the new tool.

What initial comments did I hear? First comment was from the product
manager: "It doesn't contain enough theoretical, conceptual material."
A word of mute protest was on my lips; after all, the whole idea was
to get away from the notion that the user had to sit down and master
top-down engineering. However, I gave in and wrote some introductory
material. That material multiplied like rabbits; before long, I had
over 100 pages of introduction before the user saw the opening screen!
I saw what was happening: the project manager was still thinking along
the lines of what was once the norm in technical documentation: send
your reader running to mainline caffeine just to get through the
preface. It was, therefore, little surprise to me to hear after the
Beta product was being tested that users found the book too cumbersome
and lacking in a quick start introduction. My initial reaction had
been right; I had shot myself in the foot by not standing my ground.

What could come next? I had to write a quick start tutorial, keeping
in mind the same things that I had originally intended to do. Then
what did I hear? Some user who had already successfully developed
applications in Access, Approach, and every other database tool on
earth, for all I knew, said that the tutorial didn't start with
enough theoretical, conceptual material! I couldn't help but remember
Jimmy Hatlo's "Urge to Kill"!

I all but dumped the whole project. It was only my sense of
responsibility that kept me from just chucking the whole thing
on the spot. However, I then decided to take over in every way.
I kept the documentation positive, encouraging, and, if anything,
kept telling the new user what a success he/she was, as if I were
sitting next to him/her. I knew that everyone wouldn't like it,
but when I was a child, I read a story about the man who tried
to please everybody and failed. He must have been a technical
writer!

What it boils down to is this: nobody is going to get 100%
adoration from a reading audience, CERTAINLY not the audience
that reads technical documentation! My own feeling is that the
"dummy" may indeed be a dummy, but he/she doesn't have to be
made to "feel" like one! Am I right or wrong? I guess time will
tell as the documentation is read by the users of the new
product. Meanwhile, I can't lose sleep over it; I've got too
much else to keep me busy.

Perhaps the thing that makes the difference for me is that, as
a former musician, I've all too often been treated as if I were
the "dummy"; I write basically for people like me, who started
from nothing and developed into plenty of nothing. I believe
that just believing that a person can succeed is more than half
the battle won. My in-house test was dealing with my wife, every
computer instructor's worst nightmare: the one who spits over
her shoulder when she hears the word "computer" and treats the
mouse as if it were a gnawing rodent. Several times I saw her
eyes fill with tears as she learned what a double-click was, and
she cursed the sadist who ever decided that computers should be
allowed without first procuring a license for a firearm. What
helped her become proficient in word processing in the end? Not
being told that she was a dummy, because she isn't; it was telling
her how she could, and would, succeed.

Maybe saying that something is "for Dummies" makes it sound easy,
but "for the discouraged" might be more accurate. That has always
been my policy; thus far, it's worked.

- Moshe