Re: Using Contractions in Software Manuals

[David Cramer <dacramer -at- VIDEON -dot- WAVE -dot- CA>]

>"The contraction-two words combined into one, as in don't and I'm -seldom
>gets a fair shake from English teachers. It may be tolerated, but it's
>looked down upon as colloquial or, according to one expert, "dialect" (what
>a slur!). Yet despite it's esteem problem, the humble contraction is used
>every day by virtually everyone, and has been for centuries. Quaint
>antiquities like shan't (shall not), 'tis (it is), 'twas (it was), 'twill
>(it will), 'twould (it would), and even 'twon't (it will not) are evidence
>of the contraction's long history.

Whoa!! I'll (I will) bet that O'Conner never said "Yet despite it's esteem
problem". How many of you would like to join me in starting a "Stamp Out
the Wrong It's" internet watchdog group? We put together a form email
explaining the correct use of "its" and "it's" and spam every writer who
it'ses when they should've (should have) itsed.

In regard to the appropriateness of contractions, there are probably
several issues to consider: culture, tone, and history for starters.

Cultural perceptions play into the situation because contractions are
connected with cultural negatives, e.g., poverty, lack of education,
rebellion, etc.

Tone plays into the situation because it is implicated in how the cultural
perceptions are created when one reads or hears contractions.

History plays because language is not static, and the perception of tone is
subject to shifting over time, affecting the perceptions of culture.

I have no problem with using contractions in software manuals per se,
simply because there are a lot of different kinds of software manuals. I
think part of the controversy over this issue is based on the fact that one
TECHWhirler is thinking of one kind of manual, where contractions would
sound out of place, while another TECHwhirler is thinking of another kind
of manual, where contractions would be appropriate. I don't think it's a
very big deal. Either the tone is appropriate or it isn't, but it better be
consistently maintained!

Laurel Nelson <Laurel_Y_Nelson -at- NOTES -dot- SEAGATE -dot- COM> brings up yet another
interesting issue in presenting the following:

>{bmc IMP.BMP} You cannot create a BOM and add future changes in the same
>ECO.
>
>{bmc IMP.BMP} You can't create a BOM and add future changes in the same
>ECO.

This is an excellent point. In one way it's a different point, in another
way not. Kind of a side effect of the way contractions work is to dimish
the significance of the contracted word. So it is true that "cannot" puts
more emphasis on the "not" idea; and Laurel's point is that the reader will
be able to understand and remember the first variation better than the
second. On the other hand, if the context of the example is that it is of
UTMOST importance that no users go off creating BOMs and still expect to be
able to change ECOs, then one can imagine that the contraction would work
fine as long as this point is clearly made:

>{bmc IMP.BMP} THIS IS IMPORTANT! You CAN'T create a BOM and add future
>changes >in the same ECO. Once your BOM has been created, you're stuck
>with that ECO for
>the rest of your LIFE!

Regards,

David

David Cramer, Process Innovation Evangelist          87-1313 Border Street
PBSC Computer Training Centres (an IBM company)      Winnipeg MB R3H 0X4
Corporate Office Research & Development              Canada


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=