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: Work around..... From:"Susan W. Gallagher" <sgallagher -at- EXPERSOFT -dot- COM> Date:Thu, 17 Dec 1998 11:35:32 -0800
David John wrote:
>>David John replied to Toni Lee McCreash:
>>>
>
>Ah, 'standard terminology... In my opinion, we technical writers ('technical
>communicators', or whatever) have a duty to use language and methods
>appropriate for the target audience and also the PURPOSE AND TONE of
>whatever we are producing. The notion of a 'standard terminology' does
>little to help in this respect.
Ah, but using terms that are unfamiliar to the target audience because
we don't "agree" with the terms they use is okay???? Hmmm. Your argument
belies your stance, I think.
>
>... One of the
>ways we can needlessly introduce confusion is by using language that may be
>doubtful, when there are plainer alternatives.
My point exactly.
>
>...If I understand you right, you
>are saying that I shouldn't just be avoiding the use of what I consider to
>be a suspect expression, but I have a duty to use it, and to draw attention
>to it as well! This is unacceptable counsel, especially as regards this
>particular expression: 'work-around' (or workaround, or whatever). As I
>understand it, a work-around is a suggested fix for a regrettable
>temporary defect in a process or a product. It's something you
>apologetically tell users about in a readme file or by word of mouth, or
>through field support people. You don't shout it from the rooftops,
>publish it as if that's part of why you're in business.
I provide a service to my customers and to my collegues in tech support
by including a "known problems and workarounds" section in release notes.
My audience needs to know this. They're developers. They know that soft-
ware isn't perfect and they're not particularly fond of surprises.
>...The main
>reason for getting familiar with the language of our users is to be able to
>understand the problem domain; we don't have to repeat what they say in the
>way they say it.
Unless, of course, we'd like for them to understand what we write????
>We are in the business of transforming more or less raw,
>unusable information, and the transformation has many aspects, in which we
>are the experts. Remember, that's supposed to be why they hired us.
Yup. And the value I add is the ability to take a spec and a bunch of
programmer notes and turn it into a manual that programmers can understand.
Seems to be enough in the grand scale of things.
>If we
>are unwilling or unable to provide this added value, then perhaps we ought
>to leave technical communication to the people who like to call a spade a
>spade, and then where would we be?
Idunno. Surrounded by a bunch of satisfied users?????
'Cause, frankly, using the methods you propose, our track record isn't
so good, y'know????
