The post quoting tekwrytr@hotmail.com provoked "Snooty McTooty" to write a spirited response (lifted out of the obscurity of the comments to that post):
Posted by Nicholas at October 22, 2007 04:46 PMAs a snooty technical writer myself, I have a few issues with this post.
The author states, "If there is a future for TW, it lies in the area of facilitating knowledge transfer, rather than an obsession with style, form, and consistency."
That's a no-brainer. I think we can all agree that the quality of instructional content is far more critical than the style, form and consistency of the writing itself. I don't think any technical writer would argue otherwise. Although many technical writers serve as their own editors, the processes of writing and editing are distinct. Although it is good to keep style, form and consistency in mind while writing, they are all things to double check during the editing process. The goal of technical writing is to clearly communicate technical information to a (typically) non-technical audience. The only way to achieve that goal is through quality instructional content. Duh!
Also, I think we can agree that as long as humanity creates inherently unintuitive things (from software to garage door openers) there will always be need for clear, concise operating instructions, and thus a need for technical writers. Implying that the future for technical writing is somehow threatened, outdated, or unnecessary is alarmist and absurd.
The author states, "Documentation is not used by the end-user because it is awkward, poorly organized, and in many cases, indecipherable for a user seeking task-accomplishment assistance."
Then why do any of us continue to be paid for our services? If the work product was always horrendous, why is there still a need for it? I have seen many examples of quality end-user documentation.
I do agree that users are primarily interested in task-accomplishment assistance. Users don't want to read an entire manual to figure out how to perform a task at hand. If the manual has a table of contents and an index, guess what, they typically don't have to read every word of the manual. They can use an inventive device called a page number and look up the precise page of instruction relating to their task. Task level assistance can also be achieved using interactive tool tips, context sensitive help files, and in some cases simply writing out pointers on the application itself (many Web-based applications provide instruction right on the application’s page). If a client isn't willing to budget for this level of assistance or for quality documentation, it's the client's fault, not the technical writer's.
I agree that every effort should be made to facilitate user instruction; but at some point users must stop whining and read the instructions. Yes, no-one likes to read instructions. Most of us like to jump right in and start using the application or product. But after we've broken the product or get stuck using the application we eventually have to break out the instruction manual to understand how to accomplish our task.
One last note. Implying that Linux is not a widely used operating system because its documentation is confusing is an extreme oversimplification. What about the fact that Windows comes pre-installed on most PCs? What about the fact that Windows is the standard operating system for most businesses? What about the fact that Windows has a consistent and reasonably easy to understand GUI? What about the fact that Windows ships their OS with a large driver pack? What about the fact that there is a standard process for installing and uninstalling applications under Windows? What about the fact that, for typical users, maybe, just maybe, it IS easier to use Windows than Linux? Linux is languishing because of poor documentation? Come on.
Also, why abbreviate "technical writing" throughout this post? Is it that much of a burden to type out?
TWs ftw!
Visitors since 17 August, 2004