I'm sure there are many contexts in which this is a good idea.
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.
There isn’t that much latitude - the “up reversal” and “essential” options don’t really apply here. That only leaves “Abort or Undo”. The concern here is with UIs feeling snappy, so we’re not talking about the type of long-running task where abort applies, which leaves Undo. So - no longer is it a simple matter of “just use the mousedown event, stop overcomplicating UIs by adding things like long press and drag/drop that force you to use mouseup events”, it’s a much more complicated matter of “use the mousedown event and also implement a comprehensive undo system”.
While my own habits agree with you, there’s a gold nugget in the replies to address accidents:
> 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.
Yes. Humans experience regret, "consent" is mostly a trick we use to get people who experience regret to blame themselves, not us, for what happened.
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.
But the scammers don't control your UI, the UI belongs to the browser.
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).
>I'm sat there until I either realise that it's a scam or I give up
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.
Undo is a good standard for nearly all actions in nearly all software.
(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.)
It's a perfect example, that rule is not there to make it easier to play the game, it's there to make it harder.
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.
(Physical button, but…) There are many reasons why I dislike the Apple Touch Bar, but the most important one was that – as a software developer – I’m used to resting my finger on the F5 button.
I am in mouse down camp. When it comes to dragging off a button to avoid triggering, I've done it many times, but it always feels wrong. It's like I'm taking advantage of faulty behaviour. Because of that instinct I'm inclined to believe that there's a better alternative available, like being able to undo easily.
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.
He also isn't making any sense. Why would someone keep in memory all the times something did what they expected? I am absolutely certain that if all buttons were act on press, there would be quite a few painful memories. Every time I encounter act on press it sends me.
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.
In many ways, on release is even worse for shaky hands. Imagine trying to use the vote icon next to this comment with your hand shaking. You need to both click and release without leaving the icon, which is extremely small.
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.
I recently had this debate with my friend, who built this fun test to see how much latency was actually added by waiting for mouseUp: https://click-duration-timer.vercel.app/
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
This causes any of the interactive elements on a page to trigger their onClick action during the mouseDown phase rather than onMouseUp. It's probably not perfect, just a scrappy user script. But omg it is so much nicer to browse with this enabled. And I say that as a hater of the original idea with strong opinions.
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.
That's a great point. Dragging on any of the interactive elements currently fails. Building in the cmd+click option to bail out makes it possible, though.
I had an e-scooter where a double click on the mode-select button would turn on the light and respond with a little beep. A single click would just switch the mode with no beep. To this day believe that the beep always came before the second click. I tried to trick it by clicking it once and only thinking about the second click — and the beep never came. But once I committed to the second click, I swear it would beep a fraction of a second earlier than that happened. Whatever it was that the button was connected to, it was insanely fast, just immediate. My brain had been so hardwired to expect every human-machine interface to have a delay, that the button responding immediately to the second click felt unnatural, broken, magical, and honestly kind of creepy.
Although this particular trick isn't possible, it is desirable and sometimes you can mimic such features which seem impossible.
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.
It was probably positive edge-level triggered (and debounced) without considering the second release event. It's a common failure of digital interfacing state machine design.
> To this day believe that the beep always came before the second click. I tried to trick it by clicking it once and only thinking about the second click — and the beep never came.
Yep. The shortcut is either to look for down-down or down-release-down, rather than down-release-down-release, but then the UX becomes inconsistent.
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.
Some cases yes, but in plenty of cases, this wouldn’t be great.
- 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.
He clearly points out that scrolling is a good enough reason t o break the rule.
>- 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.
Well, you don't have to abandon double clicks in probably the most common case, where click is a non-destructive action like "select" that can precede the double-click action (e.g. "open").
Funnily enough I recently noticed that the X app on iOS started doing this for me… on ads. If I place my finger on an ad while scrolling down, without fault it opens the ad overlay sheet. I guess that’s one way to increase CPC revenue
> Game developers, with simple UI toolkits, tend to get this right more often
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?
I don't think I have ever seen auch a system. Seems incredibly weird, as you can't reliably distinguish between the two. A user moving his mouse during a click is it a drag? Or is an activation? That is very hard to distinguish.
In my experience games with auch an inventory system have e.g. a double click for use.
The problem you're describing is only a problem with Act on Press, which is why it's normally Act on Release, so I don't understand how it's irrelevant to his point.
I'm not sure I've ever seen a game which requires a double click for use. Do you have any examples?
>The problem you're describing is only a problem with Act on Press, which is why it's normally Act on Release, so I don't understand how it's irrelevant to his point.
No, it is also a problem with act on release. How do you distinguish a drag and a click?
If you release while still inside the button it's a click. Try dragging a random clickable element in the browser (like dragging a link into this comment box) and you will see the same behaviour.
World of Warcraft action bars are this way by default, and I imagine other MMOs do as well. Drag a spell onto the bar to be able to use it more easily. Click it (or, ideally, press an associated hotkey), and it casts the spell or uses the item. Drag the button, and it will make it so that you are again moving the spell around to put it on a different action bar slot (or remove it).
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.
Dragging items to a hotbar is very common. Pretty sure Minecraft does it. Black Desert does it. I think Barotrauma does it. Space Engineers, Terraria... I could keep scrolling through my Steam library but I think I made my point.
This reminds me of fastclick.js [1], a library developed by FT to eliminate the 300ms time lag that used to exist between click and navigate on mobile browsers. The lag allowed for dblclick events but has been removed in recent years.
The "Leave" button in MS Teams only works on release. Towards the end of a video call, as the meeting is wrapping up, I press and hold the Leave button, waiting for the optimum moment to release...
I confess this tweet surprised me. I can't think of many games (any?) that only act on release. There are plenty that have release activation. Famously there is the video of Mario 64 using half an A press. I don't know of many that only do something on release, though. What games do this?
I am not at all surprised to know that Android had some questionable default behaviors.
Fair, I think. Most toolkits usually have a down and release event, with click being a shortcut on those. Has an odd parallel/collision with keypresses, as those also have repeat events, often? I don't know any system that has click repeats as a configured thing.
"Devil Daggers" has an action on release scheme, you play as a floating hand that shoots daggers with two firing modes, a "shotgun" like dagger blast, and a "stream" of individual daggers. The first, which you activate by clicking then quickly releasing, does a lot of damage, but suffers from a cool-down. the latter, which you get by holding for a certain amount of time, is good if you need constant damage.
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.
In MOBAs like Heroes of the Storm you can configure your hotkeys in 3 modes: on-press, on-release, and normal.
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.
Nitpicking, the "half an A press" terminology refers to getting effects from having A held, not from the release (I could nitpick this example more but I'll stop there); something like Street Fighter might be a better example for an effect specifically from releasing.
Fair nitpick, I think. Many games have "charge" moves that do something on release. Mega Man in later versions come to mind. Any game that lets you hold on to walls and such. Mario would be what comes to mind for those, as you would hold on to walls until you let go of the button.
I wrote in a different stand alone comment but I think this has to do with button down being just unreliable for mechanical buttons. The system always has to do some debouncing, so most GUI systems only listens to button up, and only in games the down event is used with extra caution.
Debouncing was literally several classes in my college years, as I recall. Can definitely be more complicated, but I find the anecdote of a team trying to insist that it isn't a better experience mind blowing.
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.
Totally fair. I should have reworded. How many frameworks only send clicks over and don't have both down/up events included? Key presses usually have a repeat event?
We don't usually go so far as MIDI does with speed of press and such, but that is a fairly old concept.
Yeah, I meant it more as evidence that things aren't limited to on press. That said, I think the other comments were clear that I missed the point that games get this right, by and large. :D
I wanted to see how consistent this may be in practice on mobile iOS, focusing only on elements that are "tap" only.
- most elements are ON RELEASE
- except the phone number entry or passcode entry, these are ON PRESS
- but the "backspace" button is ON RELEASE
I'm guessing because there are so many other interactive options on iOS (touch hold, hold drag, 3d press, swipe) this proposed paradigm is less likely to have much impact.
Very contextual. I've been appreciative of act-on-release in UIs where I can click a button with the mouse and then drag away from the button before release to change my mind. And that UI behavior has been around forever, way before touch UIs.
I am 52 and have been using computers for most of my life and there are still times when I realize I have clicked the wrong button, and slide my pointer/finger off of the button into a safe space before I release. Carmack sure does have a preference that would result in me swearing and reaching for undo, or swearing because whatever minimum viable webshit app I’m using doesn’t have an undo.
> ... and slide my pointer/finger off of the button into a safe space before I 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.
He better not quit his day job as a graphics programmer. Act on press is a terrible design the vast majority of time and almost always has unintended consequences and is incompatible with other interactions, such as disambiguating something that can be clicked but also dragged.
> 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.
That study makes sense given that it's about virtual keyboards, and most users expect keyboards to be act on press (since physical keyboards are). The issue, for me, is that he's extrapolating from that study that all (or nearly all) systems should be act on press, which doesn't actually follow.
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.
In some safety critical software, it's important to do the opposite, to provide a means for a user to abort partway through the action of clicking (by dragging their mouse off the control with the button still held.)
Wouldn’t that likely make most presses take longer, since the cancellation timer would surely be longer than the duration people keep the button pressed before releasing?
Institutional UI/UX departments always seem to overthink this stuff and get it wrong. I would love it if there was a rulebook we could reference so this sort of thing isn't always a battle.
> This is a UI design hill I will die on... 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
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
I'm not sure this should be applicable to critical actions, like completing a bank transfer, buying shares, etc.
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.
Why? If it is critical give the user a confirmation screen where he can review his order.
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.
I'm speaking from personal experience, I don't have quantitative data. If I'm on a review / confirmation screen I would prefer the action to be triggered on release - that's how other forms work and I gotten used to it working that way. Getting another popup to confirm the action would be annoying.
For other actions like adding stuff to a basket, increasing number of items etc, yes use on press.
>Getting another popup to confirm the action would be annoying.
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.
On my banking app I get a review screen as you described and I wouldn't be happy if the submit action would be triggered on press, because I'm already used to confirmation actions to be triggered on release.
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.
I disagree with Carmack on this, I'm on the other hill.
The press-on-release affords me the chance to bail at the last minute. It's probably because my brain is defective, but then consider it a handicap aid! But something about the way I work, makes it that my last cognition will often happen as I'm holding down the button, and it's not uncommon for me to realize that "oh shit, this is the delete button, I meant to save!" and! With the do-on-release, I can keep holding down the mouse button and carefully move the cursor OUTSIDE the button, so that the action is not executed.
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.
As much as I would also like to drop double clicks and long presses and only use fast and discoverable interactions I think that ship has sailed...
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.
If you implement act on press, and it's "destructive" in any way, and you don't have a way to reverse it, you are wrong. Carmack is usually smart, but this is a hill he'd easily die on any day of the week.
Not to mention this is the way that physical buttons work in the real world. People would be immensely annoyed if suddenly doorbells, elevators, light switches, etc. didn't operate until release.
I think the difference is that you can touch physical buttons without activating them, making it a two step process analogous to activation on release on touch screens.
Physical buttons use edge and level triggering, and depending on the system either leading or trailing edge triggering. They don't universally use leading edge triggering.
- 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.
When it comes to actions (by which I mean commands) in conventional UI, all desktop platforms follow the well established convention: keyboard acts on press, mouse acts on release. This doesn’t mean that there aren’t controls that react on mouse down—focusing an input field, for example, is a mouse-down thing, and you can immediately start things like text selection thereby; and draggable things like scrollbars are also naturally exempt from this. But basically everything else, certainly things that are for taking actions, should act on release, if you’re activating them with a pointing device.
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.
Isn't it carry over from anti-chattering/de-bouncing feature?
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)
... which results in classic MacOS style behavior of button press greying the button without action, and that is cute.
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.
Debounce makes act on release a lot harder than act on press. If you want act on release with a bouncy switch you have to actually act on N number of milliseconds of switch open to ensure that it's an actual release and not a bounce.
Act on press is simply just rising edge and then suppress for N milliseconds.
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.
> A related UI principle is “make everything easy to undo”,
But of course, there are plenty of actions that are fundamentally impossible to undo, such as sending an email.
So either you make those actions triggered on mouse-down, which means they're easy to do by accident, or you make them inconsistent with the rest of your UI.
> there are plenty of actions that are fundamentally impossible to undo, such as sending an email.
That's just a lack of imagination. Gmail and others allow undoing a misclicked send no problem. In cases it doesn't matter to the user if the action in practice doesn't happen exactly immediately, delaying it a bit while instantly providing feedback in the UI gets you the best of both worlds.
That works for email, but less-so in Slack or IM in general.
I did once play with a hacked-on delay-send setting, but any delay must be long enough to allow you to register making a mistake first, e.g. 3 seconds) but when it's that long it ruins spontaneity and the rapid back-and-forth experience when chatting away - in that situation I definitely prefer send-on-button-up, not send-on-button-down.
Extremely anecdotal - but for whatever reason I read the first two paragraphs thinking JC was talking about marketing. I was both quite confused by the fact that you should have 2 events, one for the press, and one when you release. I thought that "the thing" was some allusion to a marketing concepts that I wasn't familiar with. I was also quite saddened that John Carmack would post about marketing. Turns out I just need to learn how to read.
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.