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: Programming Tools -- How Prevalent Are They? From:Averil Strauss <averil -at- LEGENDCOMM -dot- COM> Date:Fri, 31 May 1996 10:05:30 -0400
>>>I recently saw an employment ad for a Technical Writer in the Boston Globe,
the more technical that a Technical
>Writer is, the more independent (and employable) they are. A manual on
>running a complicated piece of software may be written with perfect
>English; however, if the instructions are incomplete, inaccurate, or
>inconclusive, how is the user aided?
YES!
>A Technical Writer who grasps the concepts of the
>programming/application of which they are documenting creates less of a
>burden on the Engineering staff.
> I find that there is a much better chance that Engineers will provide
>useful information if you approach them prepared rather than with the
>"blank page" journalist/interviewer approach. By knowing some of their
>environment, your questions are direct and minimize the chance of
>misunderstanding.
Also the engineers don't get bored trying to explain all the details which
are obvious to them. We should look on ourselves as translators from the
engineering world to the user world.
<snip>
Often, I am one of the first people to run
>an application with separate pieces trying to interact.
And that means that you find the bugs and figure out better ways for the
user interface to work. When you provide this type of feedback, the
engineers realize that they need you and nearly all start to bring you in on
design sessions.
>In my opinion, today's job work environment requires that a writer
>spread their skills wide as well as deep. Writing is still the core
>skill, the job has expanded to testing, example code, on-line
>presentations, animation, hypertext, intra- and inter- net
>presentations, single source/reusable files, contact and context
>sensitivity, and other requirements that aren't covered in English
>classes.
In hardware/software environments, ergonomics may also be part of the
requirements.
Most importantly, you also need to play the role of the customer, asking
yourself what is needed in what order. Sometimes one extra button or menu
makes all the difference between a usable product and an unusable one, and
you can't fix that in the manual no matter how well you write. Just
remember, engineers get tunnel vision sometimes, focusing too hard on how to
make it work mechanically or programming-wise and forgetting that the user
won't have his skills.
And after all that, the company expects you to handle the production details
for the manuals, of course!
Averil
Legend Communications, Inc.
Makers of PostScript and Imposition Software http://www.legendcomm.com
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Post Message: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
Get Commands: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "help" in body.
Unsubscribe: LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU with "signoff TECHWR-L"
Listowner: ejray -at- ionet -dot- net
