Active, Passive, and more

Subject: Active, Passive, and more
From: JohnFGlenn -at- AOL -dot- COM
Date: Tue, 23 Jan 1996 05:42:00 -0500

%=new para indicator

** re activate vs. passive ... and being negative **

CLARITY SHALL PREVAIL.

I am pro /active/; I feel it is clearer (also less apt to be ambiguous).

Unless prohibited by contract, I encourage all writers to use the active
voice,
realizing there are times when only passive is possible.

I am strongly against /no/ and /not/, and I am pro-Harvard regarding
/commas_before_and/ in a list of distinct items.

The problems with /no/ and /not/ ... as I learned in PTW* journalism days ..
are that the words can be dropped (when text was re-keyed by keyboarders
or typesetters), overlooked by the reader, or changed during keying (by
anyone) from, for example, /noT/ to /noW/.

Likewise, it is easy to drop or overlook prefixes de-, dis, and un-,
particularly when the word is out of context.

There are alternative words, although a sentence rewrite may be necessary.
I consider such a rewrite worthwhile.

Professional engineers put their licenses on the line (at least in Florida)
when
negatives are dropped or overlooked.

As with all things, some negatives may be retained; as Shamai's opposite
noted, it is easier NOT to do something than to do something.

Re /commas_before_and/, I write manuals for the international market where
English (British or American) is a second language (note negative avoidance).

Anything to eliminate confusion is beneficial to the reader and to the
company
making/marketing the product ... a frustrated reader typically will speak ill
of the
product -- "it is too hard to use," so a hearer will look elsewhere for a
similar
product.

PARTING SHOT: Documentation is as much a part of the product as the
advertised product (hardware, software). Without documentation, the product
is incomplete. (Sorry 'both that nasty negative.)

* pre-tech writer

** Hillel: do not do unto others what is hateful to you. Hillel, who may
have been a tech writer, also said //do not make a statement that cannot
easily be understood on the ground it will be understood eventually.//
Seems appropriate for this discussion.

John Glenn (johnfglenn -at- aol -dot- com)

- 30 - / fine / sof


Previous by Author: SoftQuad, Yuri Rubinsky
Next by Author: Writers on Development Teams
Previous by Thread: Customizing documents
Next by Thread: Optimal Page Sizes


What this post helpful? Share it with friends and colleagues:


Sponsored Ads