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.
Your strong, unequivocal statements seem to preclude a great deal of the work that I and many thousands of my colleagues have done over several decades in my experience. Yes, I have written plenty of procedural documents, but I have also written feature reference guides of many kinds.
I would also suggest that you *not* tell your friendly SME engineer that his "engineering document" is "not a technical document." He will reply that this is balderdash--possibly in much stronger terms, however.
Let us use as an example the documentation sets that the telecomm companies publish for their digital telephony switches. I assure you, there are many thousands of pages that include all aspects of the system--including many pure information references that may be used for many needs of the people who own, install, or maintain the switches but are distinctly *not* procedural documents.
In fact, I would maintain that for many technical products, the documentation set should include both procedural guides and reference guides, giving the greatest assistance to users of all levels in finding the understanding they seek. While the beginners definitely need somewhat basic "howto" kinds of procedures, more experienced users may merely need to be reminded where some feature is located--and, rightfully, resent the hell out of having to dig through a procedural document to find it.
Were you, perhaps, exaggerating for effect--or has so much of my work been not that of a tech writer even though that was at the time my title and theoretically that for which I was being paid?
Cordially,
David
-----Original Message from Mark Baker listsub -at- analecta -dot- com-----
"The point I'd like to get you to is that technical communication is supposed
to be task oriented. What that means is that the subject of a technical
document is the task, not the product. A technical document is a how-to
document, not a product specification."
"A document that specifies the characteristics of a product is an engineering
document, not a technical document. A technical document is about how to
perform a task. Technical documents are sometimes packaged with a product,
and sometimes sold separately. But their subject is always the task and
never the product."
ROBOHELP X5 - ALL NEW VERSION. Now with Word 2003 support, Content
Management, Multi-Author support, PDF and XML support and much more!
Now is the best time to buy - special end of month promos, including:
$100 mail-in rebate; Free online orientation on content management
functionality; Huge savings on support and future product releases;
PLUS Great discounts on RoboHelp training. OFFER EXPIRES April 30th!
Call 1-800-358-9370 or visit: http://www.ehelp.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -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.
