Documentation - do we "Click", "Push", "Press" or "Select" a button on a touch-screen interface

Question

I'm writing some documentation for a web-based application that will run on Android tablets at the factory at which I am employed.

I am having trouble wording the steps where the users must interact with the onscreen buttons via touch.

For example "1. Enter or scan your clock number and then"... "click the button", "press the button"?

Click sounds most natural to me, but it still doesn't "feel" right.

Is the word "click" ubiquitous while explaining interaction with an onscreen button regardless of if there is a mouse involved?

Answer 1

There's no 'right' answer here. What is more important is that you are consistent within your own documentation.

Regarding touch interfaces, the typical interaction is 'tap'.

Regarding desktops, the typical interaction is 'click'.

In both cases, it's not the ONLY interaction, however, as both touch devices and desktops can be navigated in other ways (such as via the keyboard).

Personally, I prefer a more generic term such as 'select' that can be used agnostically across devices--though some have pointed out that 'select' is often reserved specifically for selecting an option.

Answer 2

As you will be using Android, perhaps refer to their own Design Principles documentation? They use 'touch';

Access the entire collection of apps and widgets by touching the All Apps button at the center of the Favorites Tray.

I would also say you 'touch the button' because isn't that exactly what you are doing on a touch screen device? That surely is the equivalent to clicking a button with a mouse. E.g;

1. Enter or scan your clock number and then touch the 'Confirm' button to continue...

FWIW, Apple use 'tap' in their iOS Human Interface Guidelines:

People use gestures—such as tap, drag, and pinch—to interact with apps and their iOS devices.

Answer 3

Click implies the pressing of a physical switch which then creates a 'click' sound - typically on devices with input devices attached (such as a mouse)

Push implies moving something out of its original position, typical of a physical button, again similar to a mouse (or moreso key) input

Press implies moving into physical contact with something, the thing being moved and the target are up for interpretation, as such this can refer to any number of motions involving contact

Select implies the choice of something over something of equal standing, typically an item from a list so is likely less appropriate for the on/off or yes/no functionality of a switch

As such, for device agnostic purposes, I'd go with 'press' if limited to the supplied list.

Tap as noted above in the answers tends to be associated with touch screen devices, in which case it would be entirely appropriate to mention in relation to button interaction

Answer 4

The Android setup screen used to instruct the user to touch the Android to begin, but I personally use tap for everything touch-related, as it's smaller, thus making instructions as simplistic as possible.

It is worth noting that if your buttons merely say Tap here then you should consider changing the text to just state their purpose, for instance Add to contacts.

Finally, if it is not clear to the user that they must tap a button, then you should consider redesigning your buttons.

Answer 5

On a mobile device you use gestural movements, in this case it would be TAP. You can use the word click but it will be read as being out of date or out of touch.

Answer 6

A button (that will trigger some action) is pressed, pushed or activated.

To do so in a web form, you can either point your mouse at it and click it (on a desktop PC) or tap at the element (on a touch device).

I would not use the term "select", that sounds as if you were choosing one from a set of buttons.

Answer 7

Personally I would think that 'tap' is the preferred description, as this also infers a touch of a short duration. If asked to touch something, a user could reasonably continue touching the thing for a significant period of time. Many UIs interpret a touch-and-hold as an alternate gesture (e.g. iOS).

'Click', 'push' and 'press' all suggest some sort of mechanical operation, and 'select' suggests that a choice of several options is being made.

Answer 8

If it's a button, "press" and "push" will always be correct.

A button, like many UI elements, mimics real life objects. "pressing" a button in any computer application has nothing to do with the method of input. Whether it's a screen you're touching, a mouse, a trackball or a straw, in the end, you're going to "hover" over the element (hence :hover in css), and make that button go down.

If you look at the default look of buttons, they even mimic real life. Often there's a light shining from the top, giving it some shadow underneath, and a gradient on the slightly rounded button. Regardless of your operating system, they'll look slightly 3-dimensional (flat design being the exception to this rule) and the down states include some shadow, representing a difference in depth.

"Clicking" is impossible without some form of real life (mouse-) button.

"Selecting" is more like :focus in css, where you're not pressing, choosing without having.

Answer 9

I would go with "select", since in fact many touchscreen applications are now touch-to-highlight/drag-to-choose/lift-to-commit. That interaction sequence deals with initially erroneous touches, and calibration issues, MUCH more smoothly than anything else. You can tap with that system, but you get better accuracy if you don't... and it subtly trains you into using the version with built-in confirmation/correction. (I know IBM developed this approach as part of the ITS project and the 1992 World's Fair kiosks; I don't know whether anyone had independently stumbled on it and published earlier.)

(Boston's public transit system has had serious ongoing problems with their choice of "tap" as the verb for presenting a proximity card to a reader. People who do what "tap" normally means don't give the system enough time to read the card. "Hold" would have been a much better description of the actual interaction. Unfortunately, since people do learn despite their documentation, they haven't been motivated to change it.)