RE. consistency in terminology?

["Hart, Geoff" <Geoff-H -at- MTL -dot- FERIC -dot- CA>]

Sella Rush is <<...curious about how other tech writers rate consistency in
terminology.>>

Much less highly than I rate accuracy and ease of comprehension, but it's
certainly something I keep my eyes on as I revise a document. I often start
out with a fair degree of diversity, then figure out during revision which
particular usage seems most effective so I can standardize on that usage. It
would probably make more sense to figure out from the beginning what I'm
doing, but that doesn't seem to be the way my mind works. (I do standardize
on some things right from the start, but others I need to use and test and
taste before I'm sure they work right.)

<<It's pretty much accepted that conforming to industry terminology is
crucial. I'm talking about the terminology (nouns and verbs) that you have
to make up as part of describing a task or concept.>>

There are two vital aspects of consistency: consistency with the standards
understood by your audience (including appropriate use of jargon) and
self-consistency within a document. It's the latter kind you're asking
about, and it's not a trivial issue. It's obvious that if you call something
a PC in one place and a Mac in another, readers are going to wonder whether
they're reading text that proposes different rules for the two computers,
but even near-synonyms such as "set" and "define" can pose problems. For
example, on the face of it, I'd assume that if you tell me to "set"
something, all I need to do is open a dialog box and flip a switch. On the
other hand, if you ask me to "define" something, I'm going to have to come
up with an accurate description of that thing before I open the dialog box
and start toggling switches.

<<I think maintaining consistency on this level is a basic part of my job>>

It is. Caveat: I'm speaking as an editor, so I'm biased. <g>

<<a developer ... said (paraphrasing):  can't we assume a level of
intelligence that can grasp that set and define are synonymous within the
context?>>

The reason English uses multiple words for similar concepts is because of
the power these words have to communicate shades of meaning, and it's silly
not to take advantage of that power to communicate effectively. There's a
concept in cognitive psychology called "cognitive load" (something like
that... I don't recall the precise term), which proposes that the more work
you make your reader's mind do, the harder their job. Think of it as the
friction that retards comprehension. As a writer or editor, your job is to
minimize this cognitive load so that readers can devote more of their mental
energy to deciding what to do about what they've just read than to
deciphering what they've just read. Since your developer probably thinks of
things in computer terms, you could explain this in terms of use of system
resources: sure, modern computers have tons of resources (RAM, file handles,
registers, interrupts, etc.), but it's foolish to design software on the
assumption that all of these resources are available exclusively for the use
of your own software. Analogously, you can assume that readers have far more
to worry about than figuring out the distinction between "set" and "define",
and the more they're worrying about, the more such distinctions slow them
down.

<<I want my readers to be clear about what they're reading, not have to
think about possible alternative meanings, not have to think about the words
themselves at all, only the information being conveyed.  If the sloppiness
causes confusion, doesn't it negate the value of accurate information?>>

An eloquent way of putting it.

<<I'm just curious about whether I'm being just a teensy bit obsessive.>>

You say that like it's a bad thing. <g>

--Geoff Hart, FERIC, Pointe-Claire, Quebec
geoff-h -at- mtl -dot- feric -dot- ca

"Technical writing... requires understanding the audience, understanding
what activities the user wants to accomplish, and translating the often
idiosyncratic and unplanned design into something that appears to make
sense."--Donald Norman, The Invisible Computer