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: Generally, what do you think of generally? From:"Murrell, Thomas" <TMurrell -at- alldata -dot- net> To:TECHWR-L <TECHWR-L -at- LISTS -dot- RAYCOMM -dot- COM> Date:Tue, 8 Feb 2000 08:02:18 -0500
> From: anonfwd -at- raycomm -dot- com[SMTP:anonfwd -at- raycomm -dot- com]
>
> Hi everyone.
> I won't take up too much time, I just have one question.
> My company has several products all of which have a few books written
> about them. As you might guess, the manager wants all of the books to look
> like
> they were written by the same person (let's not go there). I am not
> telling you this because I want to gripe/question about that issue. I am
> asking
> what you think about writing the books using a term like typically or
> generally, prior to telling what the reader/user should do. For example:
> Typically, on a rainy day you use an umbrella.
> rather than:
> On a rainy day you use an umbrella.
> My thoughts/concerns are that the former, when used in real life
> situations, is too wishy-washy. If it is something that they may or may
> not do (it is
> their call), I think they will be smart enough to not do it if they want
> to, even if you use directive language.
>
Generally, it depends on the type of documentation, the audience, and the
purpose of the documentation whether or not I think words like "generally"
are appropriate. Typically, I will try to avoid such words since I see them
as too qualitative. Usually, I prefer to use more direct language.
Fortunately, I don't have to work with people who want fuzzy language in our
documentation.