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: Oh those tender users From:"Bonnie Granat" <bgranat -at- att -dot- net> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Sat, 30 Dec 2000 23:06:50 -0500
-----Original Message-----
From: Andrew Plato <intrepid_es -at- yahoo -dot- com>
>"Bonnie Granat" wrote..
>
>> It's saying that if an end user is a nontechnical person, a nontechnical
>> technical writer is a good test subject for the adequacy of documentation
>> for nontechnical users and specifically, that a nontechnical technical
>> writer is ideal to present technical information to nontechnical users.
>> Maybe you write only for programmers or developers, but this list is for
>> writers who address a variety of audiences.
>
>That's not writing, that's quality assurance. QA people test the validity
of
>products and then report defects. Writers produce content. I do not think
it
>is fair that people who do not generate content call themselves writers.
They
>are not writing.
>
I used that language to try to flesh out what I thought the original writer
was saying, but I went on to speak specifically about writing. The
assumption is that the writer knows and understands the product.
>You are correct, it is good to test products and documents before they are
>delivered. But that job is usually reserved for the QA staff and not tech
>writers.
Right -- as I said, I was trying to understand what the original writer
meant.
>> I wonder if we aren't misunderstanding each other. I am saying that I
don't
>> need to be a database developer to write about a program that uses a
>> database, as long as I know what users must know so that they do not ruin
>> the database in the software. To imply that people who write about
>> technology must be experts in that technology is silly.
>
>You might not need to be a crack database developer, but you do need to
>understand HOW database systems work and how the product works with the
>database.
Agreed.
In essence, you need the equivalent of a "database developer 101"
>class.
>
Not agreed.
>And you **DO** need to know more than just what the users should or should
not
>do. You cannot accurately anticipate the questions users might ask without
a
>solid comprehension of the technologies involved.
>
Semi-agreed.
>As a TECHNICAL writer, you're job is to communicate information about a
product
>and/or technology to users/readers. If you don't understand the
>product/technology -- how on earth can you be sure you're communicating the
>right information? You can't. Ignorant writers cannot produce intelligent
>documents.
>
Why do you think I am arguing that one shouldn't understand the
product/technology?
>And as for the theories of style and the psychology of learning. These are
>totally useless if the person implementing those theories communicates
>inaccurate, irrelevant, or absurdly simplistic information.
Yes, I agree. But I do not assume, as you do, that ALL people interested in
these things are automatically unable to understand the products they write
about. You simply assume that anyone who expresses interest in document
design and visual aspects of documents is a specimen of a writer who can't
comprehend technical subjects. When people on this list want to talk about
these issues, you always butt in and tell people that they're worrying about
something that makes no difference at all "if you don't understand the
subject". You ALWAYS come on as if you had some secret personal knowledge
that each and every one of your readers HERE was one of those forsaken
writers who didn't understand their subjects. Instead of assuming that your
peers here are all serious about what they do, you choke their quite
legitimate interest in aspects other than strict content. A technically
accurate document that looks like hell, has misspellings, bad syntax, and
inelegant writing is not a good technical document. While being technically
accurate is certainly preferable to being technically inaccurate, a document
that is accurate but filled with misspellings, amateurish writing, and other
deficits is not a good technical document.
I maintain you can have both technical and communicative quality, and that's
what I am doing at my company. I am both editing and writing. I have the
support of my manager in what I am doing, which involves _enforcing
standards_ and _requiring good writing from the writers_ -- and writing the
books myself if I have to.
A technically accurate, ugly document with misspellings and other garbage is
a bad technical document.
A technically inaccurate, beautiful document with no misspellings is a bad
technical document.
A technically accurate, beautiful document is what I believe we all hope to
and work hard to create.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by an
anonymous satisfied subscriber since 1994.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
