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.
Subject:Re: To Dialog or Not To Dialog (#161027) From:Bill Burns <wburns -at- MICRON -dot- COM> Date:Wed, 3 Apr 1996 08:05:57 -0700
>A starting point has to be assumed (for a start, that your audience can read
>English !), I don't see the point in duplicating information, unless there
>is some specific reason why you can't assume this material is available to
>them (and usually, there isn't).
I'm not going to argue that point with you because I agree. However, where that
starting point lies on the continuum of experience is quite important and should
vary depending upon the intended audience for your documentation and the target
user for the product.
If your product is going to be used in a corporate atmosphere, you can bet that
the users are often not going to receive any written documentation on their
operating system; they'll only get the books for the unique software they have
on their system (unless, of course, the software resides on a server somewhere).
You could argue that such users should already have enough exposure to the
equipment, but I have a gazillion (that's a technical measurement) examples of
people here (many of them ENGINEERS, fer gunnussake) of people who don't know
they can press ALT+TAB to change screens or can have more than one window open
at a time.
When I write online help, I explain what every button does, what terms refer to
which screen elements, and how screens change following different actions. The
only **explicit** assumptions I make (other than a shared language with the
users and their need to use the program) is that the production trainers will
explain to operators how to launch an application and how to click on a
hypertext link to go to a help topic. Those users who don't need the overview
can skip it.
<ASIDE> Hmmm. Perhaps what we REALLY need to do is examine our **implicit**
assumptions about our users.</ASIDE>
For holistic learners (those who learn easily in new contexts and have broad
experience to aid them), assuming a higher level of knowledge is fine. For
serialistic learners, you need to give them more details about the environment
into which they are about to venture, or they will toss out your manual as soon
as they find instructions that include foreign interface elements.
The point? Make assumptions based on what your audience knows, not on what you
believe they SHOULD know.
Assembly Training and Documentation Supervisor
WBURNS -at- MICRON -dot- COM