- Sometimes the content can be scrolled, so it’s not clear when the user presses whether they intend to scroll or actually press the button. Similarly, sometimes the pressed item can also be dragged.
- Other times the buttons may be small and the user may have fat-fingered, so it’s important they can drag outside the button to cancel (or in some cases, like the keyboard, maybe select a different button).
- Some buttons have special “long press” or “hard press” actions, particularly on iOS. This is really good UI, and it only works if the button’s normal trigger occurs on release or the normal trigger segues into the long-press trigger.
- Even when none of the above apply, the user is still conditioned to expect the button will trigger on release. They aren’t going to deduce “this button isn’t in a scrollable area and is large enough and has no long-press action (or the normal action segues into the long-press action), so it will trigger instantly”.
- It almost never makes a difference to wait for the user to release. If the content loads fast enough, it will load before their brains’s reaction time (they are releasing the button before their brain can start processing new content). If you really care, to remove 0.1 seconds of latency, you can preload the content when the user taps the button, commit it on normal release, and revert it on cancel. Toggle and selector buttons have no immediate effect, so for them it never makes a difference.
On desktops it matters less whether buttons trigger on press or release, but IMO it still matters. “Long-click” isn’t common and scrolling is done differently, but there are still draggable elements, “fat-fingering”, and conventions. The thing that matters, for both desktop and mobile, is that the button or item has a “(being) pressed” state that looks different than the selected state. IMO if the button doesn’t have a pressed state, it feels more natural for it to trigger on press; but it feels more natural for the button to have a pressed state than not, and when it does have this state, it feels more natural for it to trigger on release.
UI elements that the user “taps and scrolls” (minus the text cursor) like sliders and color pickers are typically expected to react instantly to the user’s touch (and a slider or color picker in a scrollable view is bad UI, because it interferes with this). Although even these elements I’d prefer go into a “pressed” state, to indicate that if the user releases or scrolls within the control it will switch to the value at their finger, but if the user cancels (e.g. simultaneously presses somewhere else with another finger, or scrolls vertically outside of a slider) it will keep its original value.
The one place instant-trigger buttons are important is real-time game UI, where reaction time is important, hence the author’s observation. Although instant triggers don’t matter in out-of-game UI, there are reasons why they may carry over: said UI may be written in the same framework, with the same developers, or the studio may wants to make the entire game’s UI responsiveness consistent. Non-real-time games may also benefit from instant-trigger buttons, although I’m less sure of their importance in these games, it seems they are common. Perhaps a game like Shattered Pixel Dungeon would feel “delayed” if it didn’t have instant triggers, especially if you are playing it really fast, even though AFAIK time in that game is entirely determined by your sequence of inputs.
- Sometimes the content can be scrolled, so it’s not clear when the user presses whether they intend to scroll or actually press the button. Similarly, sometimes the pressed item can also be dragged.
- Other times the buttons may be small and the user may have fat-fingered, so it’s important they can drag outside the button to cancel (or in some cases, like the keyboard, maybe select a different button).
- Some buttons have special “long press” or “hard press” actions, particularly on iOS. This is really good UI, and it only works if the button’s normal trigger occurs on release or the normal trigger segues into the long-press trigger.
- Even when none of the above apply, the user is still conditioned to expect the button will trigger on release. They aren’t going to deduce “this button isn’t in a scrollable area and is large enough and has no long-press action (or the normal action segues into the long-press action), so it will trigger instantly”.
- It almost never makes a difference to wait for the user to release. If the content loads fast enough, it will load before their brains’s reaction time (they are releasing the button before their brain can start processing new content). If you really care, to remove 0.1 seconds of latency, you can preload the content when the user taps the button, commit it on normal release, and revert it on cancel. Toggle and selector buttons have no immediate effect, so for them it never makes a difference.
On desktops it matters less whether buttons trigger on press or release, but IMO it still matters. “Long-click” isn’t common and scrolling is done differently, but there are still draggable elements, “fat-fingering”, and conventions. The thing that matters, for both desktop and mobile, is that the button or item has a “(being) pressed” state that looks different than the selected state. IMO if the button doesn’t have a pressed state, it feels more natural for it to trigger on press; but it feels more natural for the button to have a pressed state than not, and when it does have this state, it feels more natural for it to trigger on release.
UI elements that the user “taps and scrolls” (minus the text cursor) like sliders and color pickers are typically expected to react instantly to the user’s touch (and a slider or color picker in a scrollable view is bad UI, because it interferes with this). Although even these elements I’d prefer go into a “pressed” state, to indicate that if the user releases or scrolls within the control it will switch to the value at their finger, but if the user cancels (e.g. simultaneously presses somewhere else with another finger, or scrolls vertically outside of a slider) it will keep its original value.
The one place instant-trigger buttons are important is real-time game UI, where reaction time is important, hence the author’s observation. Although instant triggers don’t matter in out-of-game UI, there are reasons why they may carry over: said UI may be written in the same framework, with the same developers, or the studio may wants to make the entire game’s UI responsiveness consistent. Non-real-time games may also benefit from instant-trigger buttons, although I’m less sure of their importance in these games, it seems they are common. Perhaps a game like Shattered Pixel Dungeon would feel “delayed” if it didn’t have instant triggers, especially if you are playing it really fast, even though AFAIK time in that game is entirely determined by your sequence of inputs.