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.
Perceptive. I agree this is their intent, but that
intent exists only because they do not realize that:
1. Technical writers accumulate product information
and detailed knowledge of its use, especially when not
under deadline to write the manual (WTFM).
2. Technical writers are conduits between developers,
marketing and users to ensure the product does what it
is bought to do, in all of the circumstances where it
applies.
3. Technical writers are often, as people who think
about the architecture of the program in the context
of the user experience, "user advocates" who make the
program and its interfaces function better.
4. All of these roles lead up to a participation in
the design of the product, as much as the process of
coding it (at this point, the most flexible albeit
most labor-intensive). Technical writers as
articulators can make sense of the design process, and
distill it to a logical map. They can refine this map
in a way that people caught in the trenches of
marketing, development or user testing cannot. In this
role, technical writers are an integral part of the
design process and can do more.
I have seen plenty of technological changes over time.
We cannot resist change by fighting mentalities that
appeal to business and common sense desires for
efficiency. We have to keep growing, and make
ourselves more competitive by making ourselves more
important to the process of developing and selling
technology, knowing full well that most of the profit
comes from user support.
For these reasons, I embrace the title "technical
communicator" and suggest others do as well. We can't
defend turf that isn't ours to own, but we can make
ourselves grow with the process of technological
development and take on a larger role in exchange for
greater permanence.
As this role will be somewhat more difficult than an
undisciplined hack can tolerate, it's also better for
the field.
The above might look a bit Pollyanna... I'm too
familiar with the fate of, say, DEC Alpha specialists
as market forces (unjustly) moved on. But I think it's
our best shot, based on not insubstantial experience.
I'd like to hear from more of the more experienced
writers on the list about this.
> I see a creeping desire on the part of companies to
> believe that if only they can create the cleanest,
> most precise CMS and single-sourcing solution . . .
> . the documentation will write itself? The engineers
> really *can* write the doc, because the structured
> doc interface will force them to write for users? .
> . . something like that!
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos. http://autos.yahoo.com/new_cars.html
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
