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.
Well David, I don't know about your work because I have no idea if I have
ever read your stuff. ;-) It is certainly true much of what passes for
technical communication today is about the product, not the task.
However writing about the task does not mean writing procedures. Procedures
are just one type of information. Writing about the task is about the entire
orientation of the piece. In fact, it is when you are writing reference
material that it is most important to keep in mind that your document is
about the task and not the product. That is what makes you ask if the
reference information you are creating is relevant to the user's task and if
the organization of the information best supports the performance of the
task.
> 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.
I agree that I am using the words "engineering" and "technical" in a
restricted sense here. It is frequently necessary to do this to make a
distinction that is not commonly made. Note however that to an engineer an
engineering document is a technical document (in my restricted sense)
because the engineer's task is to build the product. It is about his task.
It is not about the user's task.
---
Mark Baker
Analecta Communications
www.analecta.com
+1 613 614 5881
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.
