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.
Re: Inventing definitions (Was: What is a document?)
Subject:Re: Inventing definitions (Was: What is a document?) From:Ben Kovitz <apteryx -at- CHISP -dot- NET> Date:Wed, 10 Mar 1999 21:14:18 -0700
Ginna Watts wrote:
>Hmm, this discussion is getting interesting. The definition above sounds
>like the IEEE definition:
>" Document - (1) A medium, and the information recorded on it, that
>generally has permanence and can be read by a person or machine."
>"Documentation - (1) A collection of documents on a given subject. (2) Any
>written or pictorial information describing, defining, specifying,
>reporting, or certifying activites, requirements, procedures or results."
>
>I'll agree that this definition is extremely vague, but I think it needs to
>be.
I think this is quite a good point. I spend a lot of my time tracking down
and exorcising vagueness in definitions and descriptions of all time.
Thanks for reminding me that there are some concepts that are best kept
vague. "Technical writing" is another one.
The point of preciseness in a definition is to draw a clear borderline
between what is included and what is excluded. The preciseness is in
effect a decision: we want this and not that. To make such a decision
requires familiarity with whatever the decision pertains to--so much
familiarity that you can draw so precise a border.
But technical writing is a field where a great part of our jobs is reaching
that level of familiarity, not starting with it. So what we do demands
that we not start with the kind of preconceptions that are the basis of a
precise definition. We might well be called upon to design the appearance
of the 16-digit code on a credit card, to address not only human
readability but machine readability. Trying to pin down "document" or
"technical writing" in such a way as to exclude such a unique job serves no
purpose. It would only lead people to narrowly categorize that job in a
way that would deprive them of our expertise.
By the way, a great technical document that works precisely because it's
vague is the United States' Bill of Rights. If it was more precise, it
would have prevented a lot of arguments, but it also would have wrongly
prejudged a lot of situations that the people of the time could never have
anticipated.
