Act on Press
twitter.com
twitter.com
For many others, though, I like to be able to press, move whatever pointing device I'm using from the hot zone, and release to cancel the action. It's like holding the chess piece.
https://www.w3.org/WAI/WCAG21/Understanding/pointer-cancella...
I could get used to act on press, but this is my current muscle memory after 30 years of computers.
This is common in lots of sports, think about pistol shooting, you're supposed to shoot one handed, arm straight, shoulder to target. That's NOT the best way to shoot if your goal is to hit the target, it's the best way to shoot if you want a challenge.
John is just outright wrong.
This is a typical engineer scenario of trying to reason something as if it is a scientific or engineering fact when in reality it is just a massive personal preference.
With on click, it only requires lining it up once before executing. There's less follow-through required. And as a best practice, there is an undo button.
> Just do it, but allow it to be un-done.
No matter what the action. This might mean rearchitecting that interactive flow. It might even need deeper rearchitecting for other tasks. But “allow undo” should definitely be an option for “action on press” flows.
We should prefer (and in software this will almost always be possible) to undo the regrettable action instead of demanding consent.
In some cases we can do even better and prevent the regret itself with "Brick wall UI". Brick wall UI is a design where the thing that you definitely don't want to do isn't possible. As designers we have to put more effort in to ensure that this only arises where it's genuinely never what you wanted to do, otherwise it's just incredibly annoying.
The idea in Brick wall UI is that the user's experience is potentially, especially initially, the same frustration as if it was broken. Why won't the barrier open so I can drive my truck under the bridge? Why can't I use my login token to access this banking site and see my transfer details?
And maybe, eventually, sat at the Brick wall UI, the user realises why and is glad. "Oh! My truck won't actually fit under the bridge, I just avoided an expensive mistake" or "Wait, this isn't my bank it's fakebank.example, it's a bloody phishing scam". Or maybe they don't, for hours, or days, or weeks, but since it was never correct that's actually fine.
The Brick Wall I was particularly thinking about is WebAuthn. There could (but shouldn't) be a UI where I can say Oops, silly site has used the wrong URL, lets provide my real site credentials anyway. I can give the scammers my real credentials, they can steal all my money everybody is happy. Oh except me, I guess I'm miserable - but only after I realise what happened. Instead there's a brick wall here, WebAuthn can't authenticate to the bad guys. I'm sat there until I either realise that it's a scam or I give up and maybe phone the bank about their apparently atrocious UI (and then maybe realise it's a scam).
Well, there are ways to do this (for an easy example, just edit your hosts file). But the barrier of entry is high enough that a non technical person will give up even if they're completely oblivious.
(The main exception I can think of being games were not having an undo can often be integral to the experience. Eg Counterstrike should definitely shoot on press, and not allow you to undo bullets.)
On the note of draggable elements: don't overload affordances on UI elements. If it's draggable, don't make it clickable too. It creates a conceptually simpler experience. As for drag scrolling on mobile, that requires intervention to avoid erroneous triggering. Though when we're talking about "clicking" we're talking about Desktop + Mouse.
But that simply just doesn't work. For example, hyperlinks are both clickable and draggable. It doesn't make sense to remove one or the other because of some strange reason. There's a reason why actions are taken upon release and not upon down. There's literally no reason to take action on down.
I felt pretty strongly that I would hate triggering events on mouseDown because of how often I "cancel" an action mid-click. But I decided to add this userscript to my browser and live with it for a week:
let preventNextClick = false;
const interactiveElements = ['a', 'button', 'input', 'select', 'textarea'];
document.addEventListener('mousedown', (event) => {
if (event.metaKey) return; // allow cmd+click to bail
if (event.button !== 0) return; // handle left clicks only
// ignore all but a handful of elements
const tagName = event.target.tagName.toLowerCase();
if (!interactiveElements.includes(tagName)) return;
event.target.click();
// set a flag to prevent firing two click events
preventNextClick = true;
});
document.addEventListener('click', (event) => {
if (preventNextClick) {
event.stopImmediatePropagation();
event.preventDefault();
preventNextClick = false;
}
}, true); // use capture phase
So, if you want to have a slightly more informed opinion on the issue I suggest trying this or something like it out for a week! I can't go back to the way it was before. Everything is so snappy now.
I haven't (yet) found a case where I wished I had the mid-click cancelability I had before. I think that getting used to the idea of clicks being instant rewired my brain a bit to simply not rely on that behavior anymore.
There’s a (very) short story about a device exactly like this: https://www.nature.com/articles/436150a
"What's expected of us" by Ted Chiang:
I remember at around the turn of the century a friend showed me a neat trick many Sony MD recorders could do, which I think has since been incorporated into many (but IMO never enough) digital recorders: Time machine.
The compression needed for an MD recorder means a PCM buffer is needed, if we run the buffer all the time (after all it's just electronics) some engineer realised that this means you could choose to record audio that happened (and thus was in the buffer) before you actually decided to record it.
When one of the band members drops an instrument & it makes the coolest noise you've ever heard, you have long enough to think "Fuck that sounded so cool" and reach across and hit record and still capture the sound.
Not constantly, but as long as the camera app is open?
Does your explanation account for this behaviour?
Debouncing refers to removing the dozens/hundreds of random momentary conduction events a real physical switch makes just prior to making contact on a human time-scale that are readily visible on an oscilloscope. Without debouncing, momentary switches would be unusable.
- Browsing HN, and your scroll gesture happens to start where a link is? Before you know it, you’ve navigated away.
- Long pressing to delete an app, and the app opens in the meantime? Awkward UX.
In the majority of cases, press gestures are competing with other gestures like scrolling. Waiting until you’ve released is often the first moment that it’s 100% clear which gesture you intended. If both gestures get invoked, it will probably lead to much worse problems.
I’m sure there are cases where act on press makes sense, but I don’t think it’s as dramatic as the tweet makes out.
> For example, it should be easier to cancel an app launch in VR that you miss-clicked — it is irritating that the meta button doesn’t work during the launch process.
Or just implement an uninstall apps screen in settings. The ratio of tapping to launch apps on purpose vs deleting an app is, what, infinity:1?
Yep, UX design is all about tradeoffs. So it's important to ask: What is more important to have UX polish? Uninstalling apps, something that happens rarely for most users? Or launching an app, which most users do dozens or hundreds of times every single day?
Adding a couple of taps to the uninstall workflow, whether it be a settings screen or a way to switch the app list into a select-to-manipulate mode, seems like a good enough UX for less common tasks if the percieved responsiveness of the device is improved.
>- Long pressing to delete an app, and the app opens in the meantime? Awkward UX.
I don't think he's envisioning a world where long press and act-on-press are valid on the same object. You'd have to abandon long press and double clicks.
Long-press does indeed have to go, though.
In almost all games I play there is an inventory and a hotbar and the way you assign items to the hotbar is by dragging it. To use the item from the inventory you release the button without dragging. How else could this be done?
In my experience games with auch an inventory system have e.g. a double click for use.
(Also, this is irrelevant to his point I think.)
Some of them make it so that you have to hold shift when dragging, and that would play nicely with act-on-press, since you already know that the shift-click indicates the start of a drag.
I'm not sure I've ever seen a game which requires a double click for use. Do you have any examples?
No, it is also a problem with act on release. How do you distinguish a drag and a click?
I am not at all surprised to know that Android had some questionable default behaviors.
Again, fair nitpick.
It’s standard for the “click” event to get sent on mouse button release. I think it’s been this way ever since the 1980s.
I use on-release with abilities that require careful targeting, which causes the press action to activate targeting with the ability firing on release. You can dismiss the ability by right-clicking too. This is usually more reliable than normal targeting since the game requires very quick interactions.
It's the same in League, they're just called quick cast & quick cast w/ indicator. And normal cast, but I think nobody uses it. I feel like on-release (w/ indicator) is more popular when people can choose, but maybe not.
I like that it's configurable. Perhaps most importantly, some abilities are hardcoded to use the sensible option when only one makes sense.
> Game developers, with simple UI toolkits, tend to get this right more often
We don't usually go so far as MIDI does with speed of press and such, but that is a fairly old concept.
Granted, just the other day, I found that in GMail key repeat events are slow as heck for some reason. Made holding backspace to delete a sentence annoying.
Interestingly, the game programmed this behavior by moving the position of the hand. When you press LMB, your hand begins traveling forward. If it reaches a certain position, it will start the dagger stream. If you let go before it gets to that spot, it activates the "shotgun" and teleports the hand backward to naturally introduce a cool-down, returning to the neutral position after some time.
People figured out that, because holding the mouse down moves the hand forward, if you shotgun then re-hold the mouse button, your shotgun cool-down is much lower. Most runs will do this because it allows you to do the most damage in the quickest time, but initially learning it is really strange because you don't expect the action to be on release.
The release doesn't really do much, though? (Does it do anything, outside of stopping swimming?)
- most elements are ON RELEASE
- except the phone number entry or passcode entry, these are ON PRESS
- but the "backspace" button is ON RELEASE
Exactly the same. Now I do agree with Carmack on this but, like you, I've been "trained" that the action happens on release and so, unconsciously, over the decades, I've come to fix misclicks by not releasing inside the button but outside the button.
I don't use the mouse that much but this change would still be problematic for me.
At the very least if an UI implements that, then the UI should show that the button is released immediately (even if the mouse button ain't released), to make it clear the action registered.
I think the reason why UI designers move away from this is because on touch devices, touches have a double meaning, a short and long tap do different things, so you have to act on release.
> it reduces user errors
Act on press significantly increases user error because in most cases, it is not the norm, so when it shows up, users take actions they didn't mean to. I can't stand it when a button is act on press.
> and it is good UI design to favor them when possible
Saving tens of milliseconds in a button press does not automatically correlate to good UI design. Saving time is the only justification he gave, which is what you'd expect out of a graphics engine programmer. And he just suggested before this line that it would be good to have mixed behaviors, which makes no sense.
You'd need a study showing that subverting user expectations (act on release) by switching to act on press reduces error rates (or at least doesn't increase them). Take a web browser and make every click (even those intended to be a click and drag, like to a bookmark folder) act on press. See how much more often (or not) users use the back button for browser history, for instance.
well thats one way to demonstrate a misunderstanding of many UI
Sliding out is also exactly how you cancel events we when you realize you've made a mistake by clicking on autopilot.
Though hard to say definitively which one is better without more explicit comparison of these two styles of interactions
For non critical actions where there is an easy undo - yes go ahead, e.g. in his example for an on-screen keyboard it makes sense. If you make a mistake you can easily undo it. But not when it comes to completing a major transaction.
That is, much, mich better than relying on the user realizing his mistakes 50% into the click and then figuring out how to get the computer to not continue.
For other actions like adding stuff to a basket, increasing number of items etc, yes use on press.
Every bank system or stock trading app I ever used worked that way though. Giving an order summary seems like an obvious solution, giving the user a way to check and to unambiguously opt out if there is a mistake.
Buttons aren't there to be cancelled mid press, the interaction makes very little sense.
And just look at this comment thread, quite a few are used to this as well, so changing it would upset those users. It's also not a repeated action, so you won't really notice the difference that much compared to pressing buttons on a virtual keyboard.
For non committal action button as per the examples above - yes use on press.
Lot's of places, I want faster response (the controls in computer games, yes, of course!) but NOT in interface elements, there I want the response on release, so I have the extra opportunity to realize my fuckup and amend the situation.
This technique hides about 80 ms of latency when triggered on mousedown and up to a few hundred milliseconds for hover.
Even if I disagree with the concept in general, unless you have very simple and pervasive undo, perhaps.
A less militant solution might be highlight-on-press. We can at least ensure the UI is as visibly responsive as possible even if actions need to wait for gestures to complete.
It cheats your brain by loading the new page once link is pressed (or even hover). Not on release.
While we're talking about how things could be better, though, long static hold on a draggable item on touch devices should natively cause dragstart.
The whole point of having a release event is another UX usability principle: being able to undo a click or tap.
Having disabled players conducting real UAT to ensure UX is appropriate for a wide audience is also important.
Cancelling an event after down press is really good outside of games.
In games holding a button down for a little or a lot longer is a good stand-in for “pushing hard” which you want the game to react to.
- 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.
From time to time I encounter web systems that get this wrong, using keyup or keypress instead of keydown, or using mousedown instead of click¹. Most people won’t notice, I expect, but I suspect I pretty much always immediately notice and find them infuriating, because they break the universal convention—things that you’re used to being able to do, don’t work as you expect. Perhaps my favourite example of this was some system which would close some form when you released Escape—so when I had something else open above the browser at the OS level (or maybe it was even just a <select> dropdown! Actually that sounds right; I know I triggered this too often) and closed it by pressing Escape, the web page underneath then received the keyup, and so the Escape press closed two things in one go, which was never what I wanted.
If you can start executing an action on mousedown and only commit it functionally and visually once it turns into a click, go ahead. But otherwise, please don’t act on press, because it’s wrong.
The on-screen keyboard he mentions… well, I’m actually a bit puzzled by that, because it should completely obviously map press to keyboard press, and release to keyboard release, and anything else would be wrong, so how was there ever an argument, and in fact how else could you implement it? I genuinely don’t see any alternative, if you’re working on an OS that has the concept of keyboards already. Ultimately, I don’t think it supports his point at all, because he was implementing a keyboard.
—⁂—
¹ Note that even monitoring mousedown + mouseup may sometimes be wrong, due to nuances that can cancel the click mid-press; things being draggable is the obvious example, but I think some platforms let you hit Escape on a keyboard, or maybe have other multi-pointer quirks.
Most micro-processors has useful edge- and level-detect interrupt features that allows instant unconditional jump to interrupt handling subroutine(think callback functions) often used for physical buttons handling.
And one of common knowledge associated with that is, physical buttons tend to go through a transitional random state while being pressed, generating rapid succession of false on-off signals. This could trigger the interrupt detection feature, and while there will be little chances of memory leaks and no GC mess from this at all thanks to interrupt systems being static objects, it could still put system in a weird state and/or massively slow it down.
The most typical solution to button chattering problem is as follows:
1. have the button input pin triggered for rising edge(button not pressed to pressed).
2. upon detection, immediately disable interrupt upon trigger, optionally send button down event to OS.
3. wait a millisecond, or for whatever duration the button takes to settle.
4. while at it, re-trigger the interrupt now for falling edge to detect button release.
5. on falling edge, pass the button up and button click events to the OS, or call the onClick() callback, and configure everything back to 1.
(0. call the hardware guy cubicle for further discussions)
But the point is, it's less of a UX feature, more of hardware quirk suppression. Certainly a VR keyboard button virtually pressed by 3D spatial location of individual fingers don't require such pieces of anti-chattering code.
[expletive], I'm bad at drawing conclusions. Maybe I could say, by Chesterton's Fence principle, here the theory of Act on Release implementation is explained, and removal of fence can now be freely discussed.
Act on press is simply just rising edge and then suppress for N milliseconds.
> it reduces user errors by not allowing the focus to slide out of the hot box between press and release
No, it increases user errors by not allowing the focus to slide out of the hot box between press and release.
Yeah, in FPS or other games where reaction time matters, or just games in general, you always want to act on press.
In all other apps, act on release.
------
Act on press
This is a UI design hill I will die on, and it dismays me how often and hard I have had to fight for it.
Almost all interaction methods have a “press” and “release” event associated with them. Whenever possible, you should “do the thing” when you get the press event instead of waiting for the release event, because it makes the interaction feel substantially more responsive, and it reduces user errors by not allowing the focus to slide out of the hot box between press and release.
Even a “ballistic tap”, where your finger is intentionally bouncing off the button or touch surface, involves several tens of milliseconds delay between the press and release, and most button presses have well over a hundred ms dwell time. There is a delight in interfaces that feel like they respond instantly to your wishes, and the benefit to every single user is often more important than additional niche features.
Game developers, with simple UI toolkits, tend to get this right more often, but “sophisticated” app designers will often fight hard against it because it is mostly incompatible with options like interactive touch scrolling views, long press menus, and drag and drop.
Being able to drag scroll a web page or view with interactive controls in it is here to stay, and nets out way better than having to use a separate scroll bar, but there are still tons of fixed position controls that should act on press, and it is good UI design to favor them when possible.
In the early days of mobile VR, the system keyboard was a dedicated little OpenGL app that responded instantly. With full internationalization it became prudent to turn it into a conventional Android app, but the default act-on-release button behavior made it feel noticeably crappier. The design team resisted a push to change it, and insisted on commissioning a user study, which is a corporate politics ploy to bury something. I was irritated at how they tried to use leading questions and tasks, but It still came back one of the clearest slam-dunks I have seen for user testing – objectively less typos, expressed preference, and interview comments about the act-on-press version feeling “crisper” and “more responsive”.
So, I won that one, but the remaining times I brought it up for other interfaces, I did not, and you still see act-on-release throughout the Meta VR system interfaces.