mice don't tap and tablet-users don't click: what word can I use for all audiences instead?
I am documenting features on a web site. The audience is end users, who could be anywhere from seasoned Internet veterans to relatively new people who came for my site's content but aren't generally online for hours every day. People visit the web site on a variety of devices, from phones (mobile site, touch) to tablets (desktop site, touch) to traditional computers (desktop site, mouse), and we do not plan to make documentation variants per form factor. (The site itself is responsive and follows mobile and desktop conventions as applicable.)
The documentation style is imperative, not descriptive (for clarity and to follow widespread convention). Sometimes the documentation needs to tell the user to interact with a button or link. Before mobile, we would have said "click". People reading on mobile devices know to mentally translate "click" to "tap" when reading instructions, but it makes me wonder if they are, in the back of their minds, wondering whether mobile is an afterthought for us and what else might be wrong in our documentation, so if I can find a better term I'd like to.
I considered "select", but to experienced techies that means "highlight", not "invoke". I don't know how much I should be concerned about that when writing for a general audience. (Most of my previous work has been for very technical readers and must be precise.)
Is there a general-purpose, concise term that works in imperative voice for "invoke a thing in a UI"?
4 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
I just looked up what Borland wrote in their user manual of the Turbo Pascal UI back when using a mouse was optional and the UI could be operated also by keyboard (you don't click on the keyboard either). The word they used for buttons was “choose”. For example, this is an excerpt from their manual:
This dialog box has three standard action buttons: OK, Cancel, and Help.
If you choose OK, the choices in the dialog box are made in the IDE.
If you choose Cancel, nothing changes and no action is done, but the dialog box is put away; […]
If you choose Help, […]
If you're using the mouse, you can click the button you want. When you're using the keyboard […]
For check boxes, radio buttons and list box entries, they used “select”.
I'm so glad you asked this question because, as a staunch desktop user, reading "tap" in a how-to guide irritates me no end. (No, the entire world is not doing everything on mobile now!) On the other hand, I can see how mobile users might feel similarly about "click". Yes, terminology sometimes persists long past its origins, but I don't see proof yet that that will be - or needs to be - the ultimate fate of "click".
I favour the word press. I think it captures best the physicality of clicking/tapping actions that are relevant to almost any input device. "Press OK to continue" should be easily understood by everybody, and (to my ear at least) sounds about as natural as "click".
While I'd be OK with "select" for radio buttons or checkboxes, which are actually options being selected, I don't think it's suitable for buttons. Buttons are pressed (or pushed, which sounds less natural here). That's why decades' worth of GUI buttons have been animated to look like they sink into the screen when you click on them. The word "select" in computing contexts also carries connotations of selecting text, which is an action that leaves your selection visible after you make it. To me, "selecting" something on a form implies making a visible change to the form, but not necessarily triggering an action.
0 comment threads
Notice that you don't "click" a mouse. You point to an object with the mouse point and you press the mouse button. And the mouse button makes a clicking sound. Click is not an action, it is feedback.
In other words, the current word is not a literal description of what you do. It is a word chosen arbitrarily to represent a complex action with multiple elements.
But tell a naive computer user, someone who has never seen this class of interface before, to "Click OK" and they will be totally at a loss for what to do.
But naive computer/phone/tablet users are not your audience. Those that are not two years old are outliers and will receive instruction from the experience users around them in the basic vocabulary of computer UIs. Your audience is people who know this stuff because they do it all day, every day.
If you tell them to "Select OK" they are not going to sit there puzzling out how to highlight it. They know what an OK button is, and they know what to do with it. The verb here is actually completely a throwaway word. It doesn't matter what it is. There is only one thing you can do with an OK button, and just about every other UI element, and your users all know what it is.
So the only way to get the verb wrong is to come up with some word so unusual that it makes the user question your sanity or thier experience.
If you were to write "click" or "tap" or "push" or "touch" everyone would know what you meant. A few picky/snarky people might point out that the verb was wrong for their device, but not one of them would be confused as to what to do.
But if you want to avoid that then "select" is indeed the correct term to use, because it is the common generic term for "activate this control from among the many available". The fact that it is a term for other forms of interaction with the UI is in no way confusing to anyone with experience using these UIs, which is virtually everyone. Like so many other terms that appear formally ambiguous, it is actually completely clear in context. (If you have to defend this to technies, point out that this is polymorphism at work. Each class of control is selected in its own way using the same command. The human brain does polymorphism very well.)
Other terms have been tried, but they all sound weird and unfamiliar. And sounding weird and unfamiliar is the one way you can get this really wrong, because when instructions sound weird or unfamiliar, users lose confidence either in themselves or in the instructions, and then they are apt to do the wrong thing where they would otherwise have done the right thing with no instruction at all.
0 comment threads
Click is really the correct term. I know it is a made-up action description for a mouse or trackball. It requires on-the-fly mental replacement with tap when used with a touch-screen (phone, tablet or larger). But click is the term used, for better or worse, within the code that runs all these wonderful web sites. Specifically, it is the onclick event in all modern browsers. In other places, such as this Windows documentation, the events are "button down" and "button up" but the discussion nearly universally speaks about the "click" actions.
As far as alternatives, select is not a great option (pun intended, of course). The reason is that "select" has not one but two very specific meanings already:
- the HTML select element which contains option elements and is used to select one of many items - for this you can write things like "select a widget from the list"
- selecting (aka highlighting) text on a page (e.g., "Select All") - for this you can write things like "select text in the box that you want to move and click cut"
Using select in a more general sense dilutes the meaning of select in those two primary uses and can both confuse regular users and annoy advanced users (especially programmers).
1 comment thread