topic vs audience

["Bonni J. Graham" <bgraham -at- ELECTRICITI -dot- COM>]

David (The Man) Blyth says,

"If you pointed a gun at my head and said "Pick one: understand your topic
or be aware of your audience".  I would try to understand what I am saying.
Thus, I maintain that a topic is more important than an audience."

To me, this is like saying, "the horse is more important than the cart" or
vice versa.  You can understand your topic all you want, but if you cannot
express it appropriately to the group with whom you are communicating, you
have failed.  Similarly, you can know your audience better than you know
yourself, but if you do not know what you're talking about, you will still
fail to communicate.

>From what I've seen of this debate, and every debate where audience
awareness is dicussed, the unspoken assumption is that we KNOW our topic
already.  I think what David may be pointing out is that this ain't
necessarily so, as Porgy and Bess would say (see -- it's a cultural
reference, not bad grammar.  No! No! Put down the torches...), and I think
he's right to do so.

For example, the project I reworked right before my current one was for a
manual that was lovely to behold, and organized well, and contained the
right level of information.  Too bad most of the information was *wrong*,
because the original writer (from phone support) wasn't given or didn't
take enough time to understand the topic before writing.

And yet...when you're writing for first-time users (as I often am), you
need to be able to take their perspective, and the fear is that if you know
your topic too well, you won't be able to do that.  Right now I'm revising
a manual that suffers from this problem.  It was written by the engineers,
who know their topic, but clearly did not know their audience.  The analogy
I'm using to describe it is the Gary Larson cartoon where two scientists
are standing at a chalkboard.  On it are two sets of equations, separated
by text in brackets.  The text reads "and then a miracle occurs" and one
scientist says to the other, "I think you're going to have to elaborate a
little on step two."  The engineers described the inner workings of the
product in great detail, and wrote quite a lot about the totally obvious
parts of the interface (a paragraph on what "bold" means, for example).
They described nothing about the process of using the product, which is
what their users were going to the book to understand.  These engineers
clearly did not understand their audience, and thus wrote a manual that's
failed in its primary purpose: to teach people how to use the software.

I think both aspects are vital: we have to know what we're talking about
well enough to make the appropriate audience choices, and we also have to
know our audience well enough to know what these choices are.


Bonni Graham
Manual Labour
Director, Region 8 Conference
bgraham -at- electriciti -dot- com