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.
That's an interesting hypothesis, and one that certainly fits your situation. But it won't work for everyone. For example, my users are nursing students. Unlike your developer/users, they are not going out and developing something they couldn't find elsewhere. There is an existing body of knowledge and they need to learn it. In this case, there is a true expert/novice relationship, and there certainly needs to be a distinction between those who already have the knowledge and those who need it.
And as for "coddling" the users by hiding the complexity... I'm sorry, I don't understand that at all. Leaving out the complexity *that the users don't need* is not "coddling" them, it's meeting their needs. After all, I'm not writing to show off how much I know, I'm writing to produce a product that meets the needs of my customers.
Going back to the example of the idiot light, do I really want to know *how* it works? Do I care where the sensor is, what sequence of events sets it off, and how to change the light bulb? Not only do I NOT care about any of that, but I will be irritated as hell if you make me wade through all that useless information in the Owner's Manual when I'm trying to find what I *really* want. I want to know why it comes on and what I'm supposed to do about it (and I read the manual when it came on, so I knew it was because the bozos at the Honda dealership didn't reset it when they changed the oil). Sure, some people want/need that info, and there are appropriate places for it. But a good tech writer writes for the audience and gives the audience what they need where they expect to find it. And yes, that involves audience analysis and, God forbid, *planning* instead of simply spewing forth everything you know. :-)
====================================================
Tracy Boyington tracy_boyington -at- okcareertech -dot- org
Oklahoma Department of Career & Technology Education
Stillwater, OK http://www.okvotech.org/cimc
====================================================
>>> Bruce Byfield <bbyfield -at- axionet -dot- com> 01/02/01 03:23PM >>>
I realize that many of my comments over the last week are informed
by this attitude. But, more importantly, I also wonder whether
adopting this view wouldn't radically change many people's views on
this subject. If the end-user is no longer distinct from the
developer, no longer someone to appease or champion, or to coddle by
carefully hiding the complexity away, what sort of manuals would we
write?
I can help thinking that the answer is: better ones.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Develop HTML-based Help with Macromedia Dreamweaver! (STC Discount.)
**NEW DATE/LOCATION!** January 16-17, 2001, New York, NY. http://www.weisner.com/training/dreamweaver_help.htm or 800-646-9989.
Sponsored by DigiPub Solutions Corp, producers of PDF 2001
Conference East, June 4-5, Baltimore/Washington D.C. area. http://www.pdfconference.com or toll-free 877/278-2131.
---
You are currently subscribed to techwr-l as: archive -at- raycomm -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.
