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.
Mike wrote:
The main reason I prefer TC to TW is that a lot of what we do is not strictly verbal, but also visual. We use nonverbal symbols, placement, density, colour, perhaps even sound, as well as written sentences, to communicate. I have always done so in my work, at any rate. We research, we analyze, we test, we trobleshoot and diagnose. Is that writing? If you say it is, then you have stretched the definition of "writing" to the point where it begins to morph into something else. Moreover, our real contract with our audience is not just to "write", but to get the needed info from source to target. The job, in other words, doesn't stop with "writing". It stops when the audience has learned what they needed to learn. -- Mike WestMelbourne, Australia
The situation is not as complex (or ambiguous) as it may seem. The end product depends on what you are paid to produce; if you are not paid to produce it, it is a hobby, and it is irrelevant what label you attach to it.
Carefully crafted arguments about what TWs "really do" or how they "serve the needs of their audience" are similarly only relevant within the context of what they are paid to do. It is doubtful that the needs of the audience would receive a very high priority if the TWs were not paid to fulfill those needs. In that event, it is not the needs of the audience that are relevant, but the scope of work that the TW is paid to do.
Software development has an identical problem--developers who want to do this or that because it they want to, rather than because it fulfills a business need and is within the scope of work for which they are paid. (Which may be the reason so much development goes offshore.)
This is not a diatribe; it is a heads up. In an ever tightening economy, adding business value at every opportunity becomes increasingly important. Similarly, ruthlessly culling that which provides little or no business value is equally important. In the eyes of many managers and executives, TW in general is one of the first areas to be considered when redcuing head count is seen as a way to increase profitability.
There are arguments for the value of TW to the organization. From the standpoint of business value, the most used arguments (such as "increasing the richness of the user experience") are the least persuasive.
tekwrytrhttp://www.tekwrytrs.com/ - Contract business analysis and solutions development in Visual Basic .NET, ASP .NET, SQL Server, and XML. Specializing in cost-effective rapid application development (RAD), prototyping, and service-oriented architecture (SOA) IT solutions for SMBs.
_________________________________________________________________
Test your Star IQ http://club.live.com/red_carpet_reveal.aspx?icid=redcarpet_HMTAGMAR
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
