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.
Mark Baker wrote:
> Bonnie Granat wrote:
>
>>> Can anybody provide an eloquent argument (maybe an
>>> online article) for including definite articles in
>>> procedures?
>>>
>>
>> It's not eloquent, but here's something: writing came into
existence
>> for one reason only. That reason is the bedrock on which all
writing
>> must continue to stand.
>>
>> That is, writing represents *speech.* It stands for speech. Writing
>> is not code, or shorthand, or a test of one's ingenuity. It is a
>> substitute for human speech.
>
> That argument is a double edged sword to say the least. Speech is
> significantly less formal than writing. To argue that written
> communication should follow speech is likely to lead to losing a lot
> of arguments in the future, even if it wins this one, which is far
> from certain. A lot of "connector" words get omitted in speech.
>
I'm not arguing that it should "follow speech," but rather that the
elementary rules of the language should be observed if the intention
is to communicate.
>
> The former is not in anyway ambiguous and the argument that such a
> construct could be ambiguous in some contexts is not compelling.
Lots
> of constructs could be ambiguous under certain circumstances.
> Avoiding them all would be tedious at best, and probably lead to
> prose that was awkward and unnatural (as the overzealous application
> of grammatical purity often does.) Formal ambiguity abounds in
> English. It is both normal and correct to rely on context to resolve
> it. The point is to avoid actual ambiguity in the present case, not
> all possibility of ambiguity in the theoretical case.
>
Readers should not have to take extra time to figure out prose that
uses no articles.
> The latter, however, is unlikely to slow anyone down significantly,
> if at all. How long does it take to read "Remove the lower bracket"
> compared to the time it takes to actually remove the lower bracket?
> The most compelling argument (to an engineer) might be to point out
> that they are optimizing the wrong part of the system.
>
Indeed, what slows people down is the irregular use of the language.
> Both forms are commonly seen (and heard). In short, it's a wash. My
> advice to Scott is to save his ammunition for a more important
fight.
>
This is the fight he is having. It must be worthy enough for him to
have posted about it, so I am not likely to try to tell him he's wrong
to want to resolve the issue. Who am I to tell someone what is or is
not important? Only he can judge that.
ROBOHELP X5 - ALL NEW VERSION. Now with Word 2003 support, Content
Management, Multi-Author support, PDF and XML support and much more!
Now is the best time to buy - special end of month promos, including:
$100 mail-in rebate; Free online orientation on content management
functionality; Huge savings on support and future product releases;
PLUS Great discounts on RoboHelp training. OFFER EXPIRES April 30th!
Call 1-800-358-9370 or visit: http://www.ehelp.com/techwr-l
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
