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: style query From:"Wing, Michael J" <mjwing -at- INGR -dot- COM> Date:Thu, 27 Feb 1997 10:36:00 -0600
>I also like to "stay with the metaphor" and it's true you do press buttons.
>But the trouble is, the button usually has text on it. Then I prefer to say
>"Click OK," and not "Press OK."
>Also, I reserve "Press" for keys such as Enter, Ctrl, Tab, etc. (so that I
>can use "Type" when I'm telling someone to type in a character).
Press and click have always been terms that confuse me. They seem to
have different inferences depending on whether you write for users or
I have to be careful how I use mouse-action terminology. It sounds like
semantics, but because I write programming guides for object-oriented
applications, click, double-click, mouse-down, and so forth are specific
events triggered by an action performed on the mouse (There are no mouse
slam or mouse double-slam events yet ;^)). Furthermore, the device
under the mouse cursor (button, icon, window . . . has to be configured
to: 1) recognize the mouse event and 2) act on the mouse event.
For the programmer, click has to be detailed as to what control it
applies to, what parameters it needs and/or returns (such as whether the
shift key is also down, which mouse button has been depressed, what are
the window coordinates returned, and so forth). These parameters vary
with controls. Furthermore, the click event has to be differentiated
from mouse down, mouse up, and a mouse move events. As a result, I
rarely get away with telling them just to click.
Mouse events are transparent to the user. However, technically, the
dialog box button is not clicked or pressed. It is a mouse button that
is pressed/clicked. When the mouse button is clicked, the control or
object under the mouse cursor signals the application that a mouse event
(and what type of mouse event) has occurred and the application acts on
it. But who wants to read (let alone explain) all that for the simple
action of positioning the mouse cursor and pressing a mouse button.
Therefore, for user instructions, I see no problem with click or press.
Personally, I use click to imply that the device is acted upon through
the mouse, and press to imply that the device was acted upon through the
keypad. I don't know what to call actions performed through a light pen
| Michael Wing
| Principal Technical Writer
| Infrastructure Technical Information Development
| Intergraph Corporation
| Huntsville, Alabama
| (205) 730-7250
| mjwing -at- ingr -dot- com