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: Writing From:Tim Altom <taltom -at- IQUEST -dot- NET> Date:Wed, 26 Jun 1996 17:28:00 EST
At 04:48 PM 6/26/96 -0400, you wrote:
>Hi all -
>I'm surprised that the recent posting for "it's vs its" has sparked such a
>controversy. I would have thought that correct *is* correct and that only a
>"boy, I hate that too" would follow. I'm surprised that any technical
>writers would defend misuse.
>If technical writing (and/or on-line documentation) is becoming more
>colloquial in an attempt to be more easily understood, are editors letting
>mistakes slide? Are there types of documentation wherein editors/employers
>would be less likely to worry about mistakes like these?
Linguists know that no language has rules, merely conventions. What we call
"rules" are actually just mutually acceptable things that we've agreed to do
in common. "Its" vs. "it's" is only a common distinction, not natural law.
Thus, editors, especially in an era when "high" (Latinate) English in
documentation is being gradually replaced by "low," or vernacular English,
are in a bind. On the one hand, any good editor wants to preserve the
language as a tool. Who wants chaos in letters? On the other hand,
vernacular is much livelier than Latinate English, more prone to shift and
change. A valid and defensible usage this year becomes next year's
stodginess. For example, I've been using contractions in this message, while
several years ago I'd be brought to book for it. (Notice how I've changed
construction in that last sentence. Is it permissible? Well...)
>I would have thought that technical writers would strive to make sure all the
>"i's" are dotted and all the "t's" crossed because the technical material is
>already difficult enough to begin with.
True, and this is what places editors in such a perilous position. On one
side is the mountain of conventionality, on the other is the chasm of
creativity. Just as teachers are always looking for new and better ways to
reach students, we are constantly experimenting with ways to make users
exclaim "Oh...why didn't they explain it that way before? That's so easy!"
That means we sometimes succeed spectacularly, but many times we fail just
as obviously. Should we be taking these risks? That's a case-by-case
decision. Or perhaps it's editor-by-editor.
>The responsibility of the technical writer is to make documentation easy to
>read and the technical information understandable. But, if a basic reader of
>a manual or guide can pick up a grammatical mistake (or an imaginary word),
>couldn't the integrity of the documentation be called into question? Because
>a basic user puts the confidence in the writer to not make such easy
>mistakes, wouldn't the other directions also be challenged? Thoughts?
Again, we have to keep many conventional things, like spelling, while
scrounging for new things to express new thoughts or new modes of thought.
And even spelling changes. How many still spell the devices that measure
things as "gauges" and how many use "gages"? And many times "imaginary" (or
perhaps better "invented") words are instantly taken to the public's bosom.
"Normalcy" was coined by Franklin Roosevelt, for instance. And Shakespeare
cooked up hundreds of new words and new uses for old words.
Just as our subject matter evolves, so does our way of explaining it.
Editors control this process, but can't stop it. I, too, treasure the subtle
distinctions in words, but I can't stand in the path of inevitable change.
Vice President, Simply Written, Inc.
317.899.5882 (voice) 317.899.5987 (fax)
FrameMaker support ForeHelp support
Makers of DuoFrame, giving you online help and paper
documentation from a single parent FrameMaker document.
TECHWR-L List Information
To send a message about technical communication to 2500+ list readers,
E-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send administrative commands
ALL other questions or problems concerning the list
should go to the listowner, Eric Ray, at ejray -at- ionet -dot- net -dot-