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: click on, select, choose From:mpriestley -at- VNET -dot- IBM -dot- COM Date:Mon, 19 Dec 1994 13:32:15 EST
Ned Beninger writes:
> boredom. While I do recognize the usage and longevity of
> the various terms and specialized meanings (select, choose, etc),
> I cannot find any reason to prefer them over 'click'. When I
If the only way to perform the action is with the mouse, then I agree,
"click" is the most appropriate term. If, however, there is a way to perform
the act with the keyboard (and there usually is), then "click" is an inadequate
term.
I use "select" because I can't be sure my reader is using the mouse: they
could be using the keyboard, or have their system set up for voice recognition,
etc. So, I tell the reader to "select" menu choices, buttons, and so on.
FWIW, there isn't really a good mapping between keyboard action and the
double-click mouse action, so I do find myself using "double-click" for
opening icons. For single-click, though (which is the majority of an
interface's interactions), I find "select" is clear and accurate, and thus
preferable over "click" which is merely clear.
BTW, what exactly are the specialized meanings of "select" and "choose"?
I don't see why their original meanings wouldn't be sufficient. "Click",
of course, is computer jargon, pure and simple, which is another reason to
prefer "select".
Michael Priestley
mpriestley -at- vnet -dot- ibm -dot- com
Disclaimer: speaking on my own behalf, not IBM's.