Button is the control that triggers some action or change of the UI when the user clicks it or taps with finger.
Size requirements
The minimum width and height of touch screen buttons should be is not less than 9 mm of physical size, and it is recommended that they are more than 12 mm.
Important microinteractions
While the software button is very basic control, it has some important interactive aspects and may have some variations in behavior, that are not so obvious.
Protection from accidental pressing
Default UI button behavior has important difference from the physical button: it triggers the event only when the user releases the mouse button or the finger. This approach guaranties, that the user may cancel the action if they have accidentally pressed the button.
Sometimes we may meet implementations, where the action happens on press, like the one mentioned below, but in most cases it is not needed. For instance, early versions of Apple Car had “on-press” trigger, and it resulted with multiple wrong clicks, because it was easy for the user driving the car to miss and hit the wrong button on relatively small infotainment display, which resulted in distractions from driving.
Multitrigger button
While in most cases the button triggers the action only once, when the user releases the button. But there can be another behavior, that is slightly closer to traditional physical buttons, that close the circuit while they are pressed. So, while the user keeps the button pressed, it may send triggers at regular intervals, or send “start” command on press and “end” command on release of the button.
This behavior may be useful for such processes, like rotating the camera of the remote machine, ringing the door bell (very straightforward behavior for classic buttons!), making video or long-exposure photo etc.
Also, this multitriggering process may start after some delay to preserve the aforementioned error-prone behavior — the user has some reaction time to release button. This delay is also used for buttons of software keyboards to imitate actual keyboards behavior, when you can write “AAAAAA” with single press.
Delayed button
For the cases, when the triggered action is critical or dangerous, the button may have delayed trigger behavior, where the delay is more than several seconds. In this case, the button may visualize countdown, when it is pressed.
Dealing with inertia
It can be an opposite case, when there is significant delay between trigger and result, and we don’t want to use the spinners or other extra UI elements to visualize the latency. In this case the button may have intermediate state, that shows, that the result is not yet achieved. It can be a tiny progress bar, if we can predict the latency, blinking of the button background or change of the button color.
This behavior is especially useful for SCADA systems and other cases, where we operate physical processes — for instance, when we need to start the engine of ventilator or empty the tank.
Combinations with other controls
If the button is expected to be used with non-interactive state indicator, it is important that design system differentiates these controls. This is where skeuomorphic approach can be useful—flat state and more raised buttons will look different for the user.
Modifications
- Dropdown button: button, that shows specific drop down panel or drop down list on click.
- Pressable or toggle button: button that can turn on or off some process or boolean property.
- Toggle state button: button, that changes the non-boolean property of some object or process.