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.
Re: Teach 'em to fish, don't give 'em fish (this one's safe
Subject:Re: Teach 'em to fish, don't give 'em fish (this one's safe From:lpraderio <lpraderi -at- CLIFF -dot- WHOI -dot- EDU> Date:Thu, 29 Apr 1993 16:26:16 EDT
Quasi-true Erik, but the bottom line is that it's the rare bird who can take
the time to understand what he or she is doing instead of just getting results
needed. For example, people don't really need to know the mechanics of an
automobile to use it, just instructions to get going and then they can take the
time later to find out more if they want.
I do say though, don't give up on trying to educate the populace. What I've
tried to do is write minimalist documentation with some information for
understanding the topic interlaced in the steps and in short intros to sections
and procedures, and in callouts. If I've documented something, I always fall
back on the RTFM mode as well-even when a persistent user says in person or
over the phone: "But I just want to know quickly." I reply that "Well that's
what we've heard from lots of people and this doc answers it quickly, so here
Woods Hole Oceanographic Institution
lpraderio -at- whoi -dot- edu
>> We have recently started looking at ways to develop "independent users"
>> who will try to help themselves rather than making phone calls first and
>> reading the documentation, if necessary, later.
> Isn't redesigning the users harder than redesigning either the
> product or the documentation? How do you propose to accomplish
I guess I wasn't clear about my previous posting. We have no control over the
product--we cannot redesign it. UNIX (without X-terms) is just UNIX, ditto for
VMS, TSO, CMS, and several other acronyms.
My point is that we want to write/design documentation to teach users to fish
rather than just giving them fish. It is easier, for me at least, to write
precise instructions on the lines of do this, do that, now do something
else, than it is to explain what is going on and why the users must do x, y, and
z. The precise instructions which just give steps don't improve the user's
understanding of the system, which also doesn't make them any more comfortable
with it. If they *UNDERSTAND* then it is easier for everyone concerned to write
and use the documentation.
If people understand that LISTSERV is a program which blindly follows (or
rejects) instructions, and TECHWR-L is a forum read by several people, they
will be more likely to understand WHY the messages to listserv must be just so,
and the messages to TECHWR-L get such heated responses.
I don't know, maybe I am completely off base, but I think that grooming
knowledgable users who understand a modicum (sp) of why they do what they
do leads to better documentation all around, in addition to making the support