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.
Great post. I have a few ideas to add for
consideration.
As IT has grown, the need for documentation outside of
a relatively small group of experts has proliferated,
and we can no longer count on IT users to have come
through a relatively homogenous, small skillset.
People are coming at the field from all over the
spectrum of knowledge, and it's often unwise to assume
they have some common basis in a computer science
curriculum.
I second your suggestion that TWs learn analytical
skills. To it, I'd add two things. They should get a
good general background in IT, from OS to networking
and basic programming, and also should acquire a
familiarity with the larger discipline of user
advocacy, UI design, and that amorphous science of
adapting technology to practical needs (it used to be
called "applied design").
I have seen too many user guides/manuals, product
information sheets, and online help systems that have
no idea how people use the product, and how to
separate granular information from theory statements.
Most of them are excessively wordy and not effective,
and many more are vague or introduce concepts required
for context barely at all. The goal for TWs in the
coming decades will be growing out of the "Get a
description on paper" mode and getting into a
user-advocate, design-centric viewpoint.
> After moving to goal-oriented structured
> documentation and XML in my last company, I noticed
> that some writers did not have the analytical skills
> required to design goal oriented documentation
> beyond the mechanics of the UI. They had to acquire
> domain knowledge of the product and have a deeper
> understanding of the outputs the customers generated
> with the product. The product was just a means to an
> end: accomplishing customer goals.
>
> If I were to make one suggestion to career-oriented
> writers now: learn the mechanics of technical
> writing, sure, but focus on your desired domain
> expertise. Having domain expertise in one or more
> areas will readily separate you from the greater
> number of wordsmiths.
____________________________________________________________________________________
Never miss an email again!
Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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-