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.
"Either it's a finished document, or it's a solid draft, or it's an
outline, or it's not technical writing. "
from Bill Swallow, below...
Man oh man, do I respectfully but strongly disagree with Mr.
Swallow. Actually, I'm at the point of getting out of technical writing,
and getting into marketing writing, in part because of too many managers
with that point of view. I think the view expressed above stifles
creativity, and prevents good writers from doing their best work.
Here's the scoop: Some people work from the top down, researching, doing
an outline, then filling in detailed information. But many very talented
technical writers -- and I know, because I am one of them -- work from the
bottom up. I gather information, start writing, cobbling together a
document in bits and pieces, rearranging and reorganizing as I gather more
information. For me, for the way I write, a document grows organically as
the needs of both the technology and user become more and more apparent the
longer I develope the document. The INTERMEDIATE result is a document
whose early appearances are rough and sloppy, with big gaping holes, but it
grows in the END into something complete, ordered, elegant, structured, and
eminently accessible. One of the wonderful things about the modern
word-processing technology (and online help technology) is that it
facilitates this kind of organic development of a document, because cut and
paste make it so easy to move things around.
I'm not knocking the first way of doing things, apparently it works well
for some people. But when managers grab a rough cut of a document off my
desk before I tell them it's ready to be looked at -- well, if they're not
happy, it's their own damn fault and not mine. My clients who are patient
enough to wait until I say I have something to show them have invariably
been pleased.
I think the important thing to remember is that, unlike computer code,
which is ultimately meant to be consumed by a machine -- and therefore can
be engineered -- technical documentation is still meant to be consumed by
humans. Creating effective technical documentation is not a technical
discipline, it's an empathic art of stepping into the users
shoes. Effective communication, including technical communication,
requires artistry, not methodology. (Well, okay, maybe there is some room
for method and technique; but I fully mean it when I say that technique
without intuition is absolutely useless, while intuition without formal
technique can still carry you very, very far.) It's the failure of the
technical writing community-at-large to appreciate this which is, once
again, leading me to leave tech writing for other domains with more
breathing room.
That said, I remain available for technical documenation work for now (till
I'm more established in marketing), and FYI I not only write very well, I
have an excellent grasp of technology itself (e.g., I can program in
several languages, have studied physics, etc.). Resume is available at the
web site indicated below, and yes, I am looking for freelance work.
Sincerely,
Steve Oppenheimer
writer -at- SPAMPROTECTwritemaster -dot- com
www.writemaster.com
P.S. One footnote. Writing the way I do doesn't work well with
single-sourcing. But then, that's another grievance I have with the recent
development of tech writing, that two different kinds of documents (online
and printed) with wholly different structural and content requirements, are
supposed to be developed from the same source text, just to save
money. Grrrrr.....
Subject: RE: Drafts -- some people not clear on the concept...
From: "Bill Swallow" <wswallow -at- nycap -dot- rr -dot- com>
Date: Sat, 21 Sep 2002 01:23:21 -0400
================
::: There must be some personality type (or types) on the Myers-Briggs
schema that simply cannot grasp, cannot appreciate that some things
(documents, songs, rough cuts of films) come in rough, provisional form,
and are simply preliminary expressions of initial stream-of-consciousness
creativity. These people, with these personality types, should be banned
from all management positions. Or,
at the very least, they should be barred by law from looking at anything
until it's in at least its third draft.
=================
I'll agree that people should understand the difference between draft and
release copy, but I disagree with what you have stated above. Technical
writing (IMO) is not a stream of consciousness endeavor; there should very
little room for creative expressions as far as content is concerned.
Managers who cite problems with this type of "technical writing" should be
encouraged to do so and should be applauded. As a technical writer, I do
not work to entertain. I work to provide need to know info to those who
need to know. My definition of a draft is a document that contains the
required technical/ procedural data but has not been proofed by SMEs/QA
for accuracy.
I can agree that some managers need to learn how to approach conflict with
tact (as do most people). I can agree that the creation of a draft is a
"necessary evil". But, and again this is IMO, the definition of
draft in technical writing is pretty narrow; either the content is there
or it isn't, and it's either accurate or it isn't. And, it's either
factual or it's not technical writing. Given all this, I'd throw a red
flag if I saw a "draft" of a technical document displaying what appears to
be "preliminary expressions of initial stream-of-consciousness creativity"
regardless fo rank/position. Either it's a finished document, or it's a
solid draft, or it's an outline, or it's not technical writing. (Hmmm,
that should keep the list server warm for quite some time. *lol*)
B I L L S W A L L O W, wswallow -at- nycap -dot- rr -dot- com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Experience RoboHelp X3! This new RoboHelp release combines single sourcing,
print-quality documentation, conditional text and much more, into the most
monumental release of RoboHelp ever! http://www.ehelp.com/techwr-l
FrameMaker-to-PDF TimeSavers Assistants let you enhance & automate navigation
in PDF doc sets (chapter tabs, next/prev chapter/pg, bookmarks, popup menus);
create interactive PDF forms, rollover popups; presentations: http://www.microtype.com
---
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.