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: Consequences of inadequate docs/training From:"Simon North" <Simon -dot- North -at- synopsys -dot- com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 27 Mar 2002 13:58:50 +0100
> --- Andrew Plato <intrepid_es -at- yahoo -dot- com> wrote:
> >
> > And one of a million reasons why it is critically important to understand the
> > products & technologies you're documenting. No amount of internationally
> > recognized process methodologies, FrameMaker tricks, or information mapping
> > theories will assuage people who got hurt because the writers (or trainers)
> > refused to learn the products they were documenting.
But it's still more of a design problem. The designer should properly understand the application area,
and no amount of documentation can compensate for it, or should.
At the risk of pulling out all the old war stories, years ago the defense company I worked for produced
really sophisticated radar tracking software. If a missile was coming at you and it lost the track, it
would project the path forwards in time. If it found a track that matched the prediction, it would
assume that it had found the missile it had lost. However, since the software couldn't be 100% certain,
it would assign this 'new' track a different object ID. Clever software. It didn't quite take into account
that the radar operator's life was at risk, and he wanted to d*&^n well know whether it was the same
missile coming at him or whether this was a new one and, if so, where was the original one ...
For military software, but it also really applies for all 'critical' software (ask the Mars lander engineers),
the design effort really has to be very carefully attuned to the application area.
Simon.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PC Magazine gives RoboHelp Office 2002 five stars - a perfect score!
"The ultimate developer's tool for designing help systems. A product
no professional help designer should be without." Check out RoboHelp at http://www.ehelp.com/techwr
---
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.
