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.
I feel completely torn between Dan G and Chris B's comments. Both make good points.
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! And that supports Dan's point. Beancounters are hoping otherwise, but there is still no substitute for effective professional communicators, and in high tech that still means writers (not talking heads. And even they need someone to write what they say.)
Then again, we do need to lay claim to our technical context, or we will lose control over our final product. I'm really concerned that we will lose control over template design and even the scoping of output. It takes a partnership of the professional communicator's mind and the XML/XSLT/etc expertise to ensure that well-written source files are combined into coherent, useful documents. When companies start thinking that they can cut corners by having only one or two templates, and generating only one or two kinds of output docs . . . all that flexibility will be sacrified to the need to simplify output. And who will make the decisions as to what is output, if we can't speak the tecchie talk and counter the bad ideas . . .
That goes to support Chris's point, which is that we need to expand our grasp so that we can continue to create good documentation.
That need is what creates titles like "Information Designer," and "Information Architect," and they can be useful if you know that your audience truly understands them. They sound ridiculously pompous in the wrong context. At this moment, "technical communicator" seems like a deceptively simple title that might fit the bill . . .
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-