My video sparked debate on Twitter, and John Carmack left some (really good) comments. Also pointed out that Chrome changes tabs on press, not on "click". "To perform an action with act-on-release you need to both hit the button, then keep the pointer on target until you perform the release action. If you have a jittery point location, as you do with hand tracking, controllers held away from the body, or old age, this can result in many fail-to-activate cases. You also want generously sized and spaced buttons, but that is an orthogonal effect."
100% agree. This is very noticeable in menus in VR where you try to click a small button and have to put a lot of effort and focus into keeping the cursor within the bounds of the box for the entire interaction. You feel a noticeable slowdown as you have to steady your hand, stop moving your body, and pay attention to the buttons rather than the content. "act-on-click/release" is only really valid with a stable cursor and that's antithetical to the VR experience and intent. VR is meant to bring the UI into your world, not pull you out of it to play "aim at the box simulator".
My Firefox on Windows changes tab on mouse press too. Interesting. Don't know why tab changes are on press while other things are generally on release. Although there is a disadvantage to act on press for tabs, sometimes I don't want to open a tab, I want to drag it somewhere else.
Tabs react on Press because there is no probability of regret. We don't submit forms / pay cash by changing tabs. In HTML however, buttons often trigger payments, likes, follows and other sensitive actions that the user may want to cancel mid-way by releasing outside. This is also why most actions on your desktop OS act on Press - while opening applications on desktop require double-click because you could open them accidentally.
@@Nekroido yes I suggest you introduce the concept of “expectations management” to your discussion. Note that before triggering a button, users do not know if a confirmation dialog will exist. We have to deal with their imaginary fears as well.
Since I was the person that implemented the original OpenGL based keyboard on Quest (originally GearVR), I thought I’d provide some additional context. John is correct wrt static UI, but I was also one of the people pushing back on his requests to apply this more broadly (such as to nearly everything). Although, I was not the person requesting a study, as the keyboard case was obvious to me ONLY because a text keyboard can easily roll-back characters if you end up holding the key (try holding “n” on the stock iphone keyboard and also note they do act on release). The main issue is still how often buttons are in scrollable UI. At one point I sent him several screenshots with all scrollable containers tinted red (most of the screen) to illustrate how common it was. In this video, the impression was given that scrollable containers aren’t a concern, but that was only because the mobile browser ignored your request to act immediately on press/down, and delayed invoking your handler until it could determine you weren’t scrolling. Thus you also weren’t getting the full latency improvements John was advocating for. In the end, there is some validity to John’s argument but it’s not as simple as just switching things over to press/down events. * UI frameworks would need to be updated to do a delayed down event while detecting intent-to-scroll * not-currently-scrollable containers are more common that never-scrollable so they could certainly benefit opportunistically at the cost of minor inconsistency * any press-and-hold interfaces (think context menus) would need to be replaced or support roll-back logic. * any drag & drop UI would need similar intent-to-drag delays Also note - on mobile, intent-to-scroll (or drag) is significantly easier/better than in VR because a touch digitizer samples input at 300-1000hz vs 72-120hz in VR for controllers and significantly less for hand tracking. The precision of your finger is also higher on mobile vs. VR controllers and esp. hand tracking (requiring bigger deadzones and/or delays). So there you have it - it’s not like the eng at Meta were dumb and didn’t want to have latency improvements, it’s just that we actually have to implement/support all this along with all the edge cases and it’s competing with a million other requests. If it was as trivial as just replacing click with onmousedown, we would have done that years ago.
It seems ideal to act on press and then roll back if the action was unintended for a lot of stuff. Of course, this is not straightforward to implement with our current frameworks.
@@niamhleeson3522 That is easy to say, but determining if the action was unintended packs a lot of challenges. Even if you define a good enough heuristics to mark the event "unintended" then you can't reliably ensure that this tell of the lack of intention wasn't itself unintended (like few pixels of drag when you only wanted to click). Plus doing all that may take more time then you're trying to save. And the problem isn't necessarily connected to the state of current frameworks. It's just due to human imprecision.
Well... Yeah, mobile browser *is* supposed to delay that. Mobile apps aren't as versatile as desktop ones, so they need to encode different inputs in different ways of tapping on screen. And that's their problem to deal with - on how to treat screen taps as mouse events.
HTMX supports "fetch on press, show on release", which massively cuts back the time it takes to navigate between webpages. It also supports "fetch on hover", which saves even more time, because it usually takes ~100ms before you press after a hover. It does risk fetching too much, like when you quickly swipe your cursor across a menu, but I believe they thought of that too and solved it for most cases.
Why though? If you type a command and hit Enter you can't undo, and it's ok. When dialog is closed on Escape press is ok. But closing with mouse on press is not ok?
@@w01dnick Right because that irreversibility is associated with mechanical objects that we interact with- like switches and buttons- but not with our hands. We can put down anything we pick up. We can hover our finger over a button and decide not to press it. We can even touch a button and then remove our hand from it. Moving the cursor on screen is more analogous to the physical interactions we have and initiate with our bodies than key-presses are.
Assistive technologies have far better support for the click event than the mousedown event. The click event also includes handlers for keyboard interactions with the space bar or the return key. Please don't forget about accessibility!
Honestly your comment needs to be pinned. Mousedown is not a suitable alternative for click, and suggesting it without further considerations is harmful for accessibility. It also breaks the workflow of heavy keyboard users and tools like Vimium
Came here to say this. As a huge proponent for accessibility, I feel uncomfortable viewing controversial opinions like Carmack's. Oftentimes, you only find what you're looking for, and nothing else. In this, Theo found the responsiveness to be better because that's all he was looking for.
@@GottZ Good idea! onMouseDown and onClick together, if onMouseDown is triggered then cancel the onClick. How would you cancel the onClick in that case?
Makes additional sense on mobile/touch screens where a long press is often required to achieve hovering. A lot of interfaces have things where there's hover effects for info popups or similar, but we lose that on mobile/touchscreens if you active on down rather than up.
I wonder if it's feasible to start doing work on mouse down, but only actually commit to it on mouse up. For example, if a user clicks a link, you load the page in the background but only flip to it on mouse up
This not only goes against accessibility, but also user expectation Imagine 99.9% of websites follow one standard, but you decide to go against it, just so your contact button has a potential saving of ~10ms I especially hope no one uses on press for important actions, such as confirmations
This is highly context dependent. In most real-time applications, like games (where John Carmack has most of his experience), the user expectation is pretty much always on mouse down. Imagine if you were trying to fight a big scary boss monster and when you go to attack with your sword, you have to release the button before the character swings. Disgusting. Nobody would ever claim "but I wanted the option to not attack the monster sometimes, after half-pressing the button, no fair!"
Wouldn't on mouse down also be better for accessibility. If they have jittery hands that means it's very likely for it to go out of the bounds of the box and not activate the click.
@@Utrilus The click event doesn't just mean a literal click. It can also be triggered using the keyboard, and when browsers are used with screen readers they will read clickable events out as clickable like links. If you use a different event like onMouseDown then I think that can only be triggered by an actual pointing device of some sort.
If the change can be reverted then it is fine to do it on the down event. That article mentions it in the "Abort or Undo" section. Although... no, it says it should be on the up event still... then I guess not.
@CottidaeSEA WCAG phrasing can be confusing. This SC states that mousedown is only acceptable when it is "essential", i.e. when mouseup is needed for something else. The part about "abort or undo" applies only to mouseup events, basically saying that dragging the mouse off the button and releasing (like the click event) is preferred.
@@joostkersjes4349 Yup, it can be very confusing. As others have written in this thread there is however clear advantages for ALL to be able to cancel accidental clicks
He's not "wrong". He's saying it feels better and he's entirely right. Are there tradeoffs for that he's not talking about? He mentioned a couple, but also yes. It's an idea. It doesn't have to be the best everywhere. Keep it in mind for a use case where it might be worth it. Personally, accessibility compliance is the part I'd care about. I let Radix make this decision for me on a lot of interactions, and I'm not overriding their behaviour to make things happen on mouse down.
For the indecisive people like us, I think onRelease is the way to go xD There can still be interaction and visual cue to actually pressing a button though. Which I agree.
One thing to mention: on things that should be on release, you can still have a little effect on press. Buttons are like that, to have 4 states: normal, hover, active (aka on pressed, no released) and disabled .... if I remember correctly. Having something like a color change on press would still maintain the feeling of very fast interaction.
as far as styling goes you're right. If my understanding is correct, Carmack's take is a step further than that, like sending a network request or changing the state of the program
@@privateanon7623 Yeah, but you need to see the bigger picture then. There are cases where it should be on release. Like allowing drag-and-drop (which Carmack mentioned). Whatever happens directly on press has be easily undoable (like on a virtual keyboard) or not that important.
@@Winnetou17 I agree with the principle. Unfortunately that kills accessibility for people prone to accidental clicks, especially those with cognitive disabilities who might not necessarily realize they did. That narrows it down to a small subset of user actions in the non important easily reversible category for me.
Mixed feelings. I can see the value in some games / high speed situations... But for most work apps etc, it speeds me up to be able to click at the speed of thought, and be able to "undo" the click by dragging off the button before letting go... That way, each click is less deliberate / more optimistic, and the few extra millisecond before I let go of the button are enough time to hit the brakes on the action if it's wrong. I feel like with "act on press", I'd need to be way more deliberate with every interaction, and it's stressing me out just thinking about it. Although to be honest I'm sure this is something one would adjust to quite quickly, and is probably less significant than any of us here is making it out to be.
I feel like every instance of "I made a mistake" is just bad UI design, if it happens often enough then the design is broken. The real solution for bad UI design is every device have a dedicated ctrl-z button to undo last action.
The best approach is probably somewhere in the middle. while mousedown events would improve mouse UX, high stakes user actions where modal dialogs aren't an option are probably best implemented through keyup type events to allow knowledgeable mouse users to cancel the interaction, even if that userbase is a tiny % However I still think user accidents should be better handled in UIs. As it stands, proper action cancellation support is nonexistent which is why the alternative of dragging the click outside the box exists in the first place Edit: Another comment mentioned WCAG success criterion 2.5.2 that ties in nicely with the subject
Word. There is (or was?) also a bug in KDE Plasma where you cannot use some modifiers involving Meta (or Windows, or Command) key in keyboard shortcuts, because it's used to invoke the application menu. Why? Because the action happens on key press, and it won't wait for you pressing other keys.
"High speed situations" make it sound like you're in one of those cheesy hacker scenes where you say "I'm in" at the end I really don't get the point of this video, if you cared so massively about quick responsive UI on such small timescales would you not be using keybinds for everything anyway? This whole thing seems like it's massively overstating the issue
I agree with him in a game. I do not agree with him on the web. People tend to forget that Carmack is a game developer, do not apply his wisdom outside of games, that does not really work. You can absolutely do things on press even on the web, increment and decrement quantity in a shopping cart for example. If it is easy to revert the change, go ahead. If not, use the release event.
> If it is easy to revert the change, go ahead So you apply his wisdom outside of games or no? This take limits you; you must interrogate wisdom to see if it is applicable in other domains, rather than having the stance that wisdom found in one domain cannot immediately be applied to another - innocent until proven guilty. Most of the time when insights are 'scoped' to the domain, it is abundantly obvious that is the case.
@@seannewell397 Most wisdom *is* scoped to a certain domain. The point is to not just take his words as gospel and do what he says without prior thought. If you try to use wisdom from basketball and try to apply it to tennis just because both are ball sports, you'll have a hard time. Some things can be similar, but you need to consider everything on a case by case basis regardless. At that point your prior wisdom boils down to a checklist of things you could try, rather than things to take for granted.
Navigation on mouse down sucks when you just want to grab a link and drop it into a new tab or a separate window as the url. The same goes for buttons that navigate you with js without being anchors so you also can't middle click / ctrl click them into a new tab that way.
I really like Cormacks advice. I get the point of cancelling clicks, and also about people being used to the current patterns. However many of us would use the Intenet more conciously if there was an immediate action. There might be even better UI expereince invented than what we have today. To those who disagree with Cormack, I have a question. Did you think through how UI needs to be adjusted? Here is something that I suggest browser vendors could give us, no matter what opinion we have on this topic on accessibilty: Let the browser users decide in user settings how the mouse-down event should be applied. Some want an immediate response, some want to keep the ability to be able to cancel the event. Everyone will be happier if we can customize the expierence, and I could think of even other ways to give each one of us a better UI experience than what we have today, if we had more choices. Configure the mouse-down event to acct as a double click, colors, gradients,, form of button, etc. accoustic feedback amd what else..
I love John, and I love that you prefaced this video with some background on why people should listen to him when he talks. I love, even more, that you still thought critically as you listened and went and tried things out for yourself instead of accepting his experience and opinion as fact. Keep up the good work.
It can be annoying though - tiktok uses the ontouchstart trigger for one of its buttons but if you touch it when scrolling, it gets pressed and the scroll is cancelled.
The best option: make it a setting. If some people like act-on-relase, they can use that, anf if they like act-on-press they can use that. A lot of problems can be solved by just introducing a setting. (Yes I know that most people don't bother going into settings, so choosing a right default is good too).
While I do understand his arguments. I really don't want accidental click when I use my touchpad, cause yeah, if I was unlucky enough to stop using the touchpad with a cursor on an element and have touch to click, damn. retaking control of the cursor without clicking is going to be hard. Being able to move the cursor OUT of the element before release to avoid clicking have saved me more than a few times. Also, it's not than phone browser knows to ignore, but that the phone do not send the event to the browser in the first place. at least, it used to be the case on older iphone if I remember correctly
The issue here is that 'onclick' means different things for different input types. Touchpads need to be safer, so probably don't want to use a cue that is going to throw up lots of false positives. This shouldn't be an argument for why I should be slowing down waiting for mouseup when I am using a mouse with reliable buttons. It shouldn't be a UI question at all, it should be a hardware question. What does a 'click' mean for that particular piece of hardware? For a mouse it could perfectly reasonably be considered to be mouse down. For a phone it will be something different, and a touchpad something different again, not to mention tech for accessibility. All a website needs to know is that you clicked on a thing. It should not be dogmatic about what a 'click' is.
I think I disagree for a good chunk of cases because of what Theo mentions at 3:09 : having events happen on mouse-up/release events is a layer of protection against misclicks. I'm more tolerant to unresponsiveness than I am to "hyperresponsiveness" if that makes sense. I think you can get 90% of the feeling of responsiveness by creating a visual acknowledgement of the press event, e.g. changing the color of the button. You can even change the color on hover (if using a mouse), which feels very responsive and telegraphs the consequences of a click.
The phone VR issue (applied to early VR headsets too) was not about fps (though 90+ fps is best for a feeling of presence within the virtual world), but about latency. The world catching up slowly when you turned your head was due to latency between you moving and the system detecting the movement, updating coordinates for the renderer, and sending the image to the screen so that photons could hit your retina. That is a chain of events where latency adds up at each step. It would not matter if you had a 200 fps renderer if the other steps had significant latency.
I thought Carmack denied that he was the one who wrote the fast inverse square root function. AFAIK it's actually unknown who wrote it. Edit: did mobile always handle onMouseDown correctly? I swear I have unintentionally clicked buttons while scrolling a lot in the past.
Yeah, scrolling down to the history section of the Wikipedia article shows that William Kahan and K.C. Ng first wrote a paper on the fast inverse square root in 1986, and then Greg Walsh wrote the exact algorithm in the late 80s.
@@JediMB I might be wrong but I think it's not the algo that john is praised for it's the WAY he implemented it in C with the weird address bitshift one liner. Don't quote me on this though. Just thinking out loud
I'm pretty sure mouse/touch actions used to have a ton more issues early on. I remember having to use an entire library just to handle simple interactions confidently. Nice to see it's so intuitive out of the box now.
@@TheBendixSA From what the article said, Carmack has never taken credit for it. It was just speculated that he'd written it after the Q3 code was made public. If you read the history section, you'll see there's a pretty good timeline of how the algorithm presumably traveled from person to person until someone at 3dfx told Carmack about it.
Was just thinking about this pattern because of several unintentional interactions with the like button on LinkedIn. Was able to cancel with the decades-old OS-level UX of moving away. Act on mouse up is a very good default. For the love of good UX do NOT just started making ALL interactions act on press because you treat the internet as gospel truth.
A me problem: I like to have to option to cancel my click action, if I have the reflex to do so. A "web" problem: Buttons on the web have this really cool feature that when you focus on it with your keyboard and press spacebar (Enter too, I think), it calls the onclick function. The onmousedown event, on the other hand, it's not called. So you would either be sacrificing accessibility by doing nothing, or give you more work to do to ensure the native behavior still works (listening to keyboard events, checking if it's "spacebar" and if it is, call the onclick function, etc etc etc).
The amount of times ive clicked a button by accident and ive saved myself by holding down left click and dragging ny mouse off of the button is crazy. I actually love that part of it
I think you could get the "best of both worlds" if you have an `onMouseUp` registered to `` that executes an undo on the last operation done in the UI if it is hit, while you have an `onMouseUp` directly on the element that simply cancels event bubbling. Then if you press and hold, then move away before releasing, it reverts whatever that change was but if you press and release then it already started doing that operation on the `onMouseDown` event as Carmack is calling for. This would require that your UI maintains an undo mechanism under the hood, but people are people and make mistakes, so that's *probably* a good idea to have anyway?
When the page layout changes from a result of a keydown, I imagine could cause problems. And if we want to mix different types of buttons, we really should have a visual language to tell the user what to expect. In VR UIs I can fully see how keydown events are better, I dont how many times I've missed a button because my hand shaked a bit before I was able to let go of the trigger. Hmm... Why are we using the pistol grip for VR cursor actions anyway? Is that really the most stable way? Could a reverse-flashlight-like grip be more stable than a pistol grip to avoid click-shaking?
I'd hate this on "send"/"confirm" buttons, where I might decide to NOT do that at the last second, and I can just drag my mouse away to cancel it. App devs, Carmack is a legend, but please don't listen to him here.
Have you missed this part: "*Whenever possible*, you should "do the thing" when you get the press event (...)" ? That implies a nuance. Send/confirm/commit buttons aren't often interacted with, and as such wouldn't affect the experience if it would be set to act-on-release.
@@alexandr0id OK, you've sent an email. How on earth are you going to "un-send" it? It's already gone. It has nothing to do with good UI or bad UI, some actions just cannot be undone. And it is good to have some way to change your mind after you accidentally click a button that does them.
Somehow I get the feeling this breaks accessibility unintentionally. It's interesting that it fired on a touch event, maybe mobile logic lets it work if it's the only event specified. Keyboard navigation is another concern. That said, it does feel nicer to fire on a down event.
@@Utrilus @Utrilus The click event doesn't just mean a literal click. It can also be triggered using the keyboard, and when browsers are used with screen readers they will read clickable events out as clickable like links. If you use a different event like onMouseDown then I think that can only be triggered by an actual pointing device of some sort.
I think that for sensitive or potentially destructive operations, buttons should act on release. Many times I have pressed a button to later think again and move the mouse over to cancel :p
@@pianochess1882 Great, now you have two "responsive" buttons and confirmation boxes everywhere. Either way for sensitive or destructive operation there should always be a confirmation box. This is just a bad idea.
@@pianochess1882 every submit button, every link click, every next button now comes with an "are you sure". You have now doubled the amount of clicks to navigate the internet, and caused people to reposition their mouse / hand / keyboard focus / etc, to the center of the page, to click ok... which had better be a browser standard, because it would be an easy dark pattern for a company to swap them around from page to page, and 99% of the population would just not notice.
If buttons _sometimes_ act on release (and I agree that they should), they should _always_ act on release so as not to baffle the user with their inconsistent behaviour. There can be exceptions if they are clearly conveyed, but it's rarely necessary that buttons trigger some action on the down press, whereas sensitive and/or destructive operations happen all the time.
It seems a huge number of people in the comments got the impression that John Carmack and Theo are advocating for using Act on Press for literally everything. I don't think that was ever implied at all - Its clear that the point is that it should be used for SOME things such as keyboards where people expect responsiveness or other things that have a "switch-like" behavior. Obviously use your judgement as to where its appropriate.
Sure, but that's not what Carmack wrote, was it? The amount of developers who believe design is about absolutist auto-anthropological self-report is horrifying; and based on this tweet, I wouldn't put it past Carmack either. I like that he's initiating the discussion, but I don't like this tweet.
Oh no, please don’t! On release is a learned behavior, people know they can still drag their mouse away from the button before releasing to prevent the action to be called. Please don’t take this away from us! For most interactions people wouldn’t even notice, because when working in an app you don’t look at the counter. Most people here are probably working on apps where there are much bigger performance improvements can be made without breaking user expectations. Most people aren’t working on a keyboard on a VR headset, they are working on some random banking app that talks to some legacy backend and every page takes 15 seconds to load. But now they saved two full frames and all they had to do was to break 40 years of learned behavior!
I don't get the argument that onPress feels more responsive. I'm sitting here pressing random onRelease buttons right now and they feel perfectly responsive to me. I much prefer being able to correct my mistake by moving my pointer/finger away before releasing than the extra 10ms or whatever that I don't even notice. Maybe in a high-paced game I would notice. For example, I can see the argument that a gun should shoot on the _press_ of a mouse click, rather than on release. But for most regular 2D UI buttons I think onRelease is the way to go.
I went through this conundrum recently when building some TV apps (with a Netflix-like 'Row/List' UI) where the interaction is using a remote control. I went with the 'press' in the end. It just felt better.
Worth also looking at using the 'PointerEvent' (onpointerdown) rather than the mouse events. To help cater for touch and stylus etc. controls, where onclick would have handled them.
It’s a tool to keep in your pocket and be aware of, but… I remember 10-15yrs ago also going “Oh wow, way faster on mouse down vs. click” and then also pretty swiftly learning my lesson about why it doesn’t make sense to always do it all the time.
And under what context is that? everyone acts as if he was suggesting it to be implemented on every kind of UI yet his beef might be the exact same issue but inverse, that nowadays everyone and their mom implement press and release because programming for mobile rotted their brain.
@@teresashinkansen9402came here to say this. John mentions all the use cases and arguments for when to use it and when not to use it. It's also funny to see people disagree with someone who is infinitely better at programming and user experience than most of is will ever be without fully listening to his argument. It's just "guy on internet said something that goes against what I learn in school." And they flip out
I use "release miss" many times to cancel click, probably some "unrecoverable" operations should use "up" event but all simple operations should use "down"
The cost of a mistake can sometimes be too high. The ability to undo an action is a crucial aspect of good user experience, allowing users to correct their errors.
It depends on what is more important, speed (or time accuracy) or avoiding accidental clicks. You can see this with Google's stopwatch. The start/stop button acts on press, the reset button acts on release. And it makes sense. That's also probably the reason why act on press is more common in games.
This might be okay for states that are temporary, however, I see a lot of alternate considerations like WCAG. I certainly want the ability to opt out of buying something after mouse press by moving away from the button as many others would. So we get the best of both worlds, how about we load the state during on mouse down but don’t commit the change until the click is registered on the element; this would be especially useful for making fetching data from the server more seamless.
I'm more in the on-release camp. So many times I do that "click - oops! - drag off the control - release" thing. For FPS games, sure, act upon press. For most UIs, nope.
This should be a user-specified OS setting. Users should be able to choose which event they prefer to count as "click", and applications (including browsers) should hook-in to this OS setting.
Please don't. There's a reason why he can't get traction for his idea. UI developers know more about how UI works than a game developer. Users do not perceive acting on mouse up to be slow. And the only users who unintentionally move the mouse between mousedown and mouseup are the ones with a shake and thus are more likely to misclick. They need the option to opt out of a click. Then there's mobile, where touching the screen can be a scroll attempt or even an errant press. People have learned that you move the mouse to cancel a click, and slide your finger to cancel a touch. Don't mess with people's intuition just to create a more "responsive" experience they won't notice. There's a reason why UI developers will intentionally add delay. Outside of games or other fast action situations, people want a more deliberate pace. They don't even perceive it as lag.
@@Logan9312 Well, no. I watched the video long enough to hear the original idea, and thought it didn't make sense, and thus had no reason to continue. I was going to say nothing, but then I saw the description where he says he genuinely plans to change how he codes. I then responded to that.
"UI developers know more about how UI works than a game developer." Appeal to authority fallacy, not an argument. "Users do not perceive acting on mouse up to be slow." I am a user and I perceive button down to be faster than button up (because it objectively is and my nervous system works). Debunked. "the only users who unintentionally move the mouse between mousedown and mouseup are the ones with a shake and thus are more likely to misclick. They need the option to opt out of a click. " They cannot control when they press the button, but they CAN control when they let go of the button? Not plausible. You're making it up. "Then there's mobile, where touching the screen can be a scroll attempt or even an errant press." This is the one legitimate argument for button up. The fact that scrolling sucks on mobile devices. However mobile users don't use a mouse and your software should be able to tell the difference between a mouse click and a touch event. "People have learned that you move the mouse to cancel a click, and slide your finger to cancel a touch." No, this is historical revisionism. Before mobile devices became the target platform for all UI design canceling a click was not a thing any user would expect or attempt. Most interfaces reacted when you pressed down. If users come with this expectation now it's because of their time using touch screen devices or because of their time using websites designed for phones, with mouse interaction being an afterthought for the developers. Step 1: You make the entire internet feel like a phone app. Step 2: Users start to expect this sort of design. Step 3: You justify that you have to keep doing things this way because of step 2.
@@forasago No. That's not the appeal to authority fallacy. That specifically refers to "cit[ing] an authority figure who is not qualified to make reliable claims about the topic at hand." It is the game designer describing UI whbis the false authority. Besides, I go on to explain why using more reasoning. It is not actually a good practice to split up people's points like that. It can misconstrue the overarching meaning. People do expect inputs to change on release. People do back out of misclicks and mis-taps. Changing that in pursuit of a speed increase can be disconcerting and actually make things feel cheap. Games need fast responses primarily so they have the time to set up smooth animation. You need a frame or two, yet you want to feel responsive. In most other software contexts speed is not required. Developers have for a long time chosen to actually slow things down. Why do you think Windows takes 400 milliseconds to show a menu?
@@ZipplyZane Fair enough, the fallacy I was looking for was Argument from authority. You're saying these established practices in UI design are the best we can have because UI designers believe so, and they are experts on this matter. You should be able to see how this is fallacious because it would mean that any time there is an industry standard it would have to be the best possible way to do things. The experts you're citing are the same people who created this standard. Also they believed in something else earlier and will likely change their minds again in the future. Yet what they think of as best practices right now is best? Obviously not an argument. "Why do you think Windows takes 400 milliseconds to show a menu?" Same reason Windows or a browser takes up a GB of RAM before you do anything with it nowadays. Bloat. Negligence.
For the car example at 8:00. Modern cars don't use a turn key anymore, it's a push button to start the car, and that push button is not "on press", it's "on hold" along with other "if" conditions like holding down the brake pedal, or checking some sensors if mechanical damage consequences are detected. The handbrake on modern cars is no longer a lever pulling a steel cable, it's an electronic button that you hold for a few seconds while the computer go through its "if" conditions, like the brake will act differently depending if parked or driving at high speed. If you mess too much with the electronic parking brake in a too short period of time, it will fall into standby mode. The turn signal lever is a toggle switch letting electric current through, so you'd think that's kind of "on press", well not always since some drivers are complaining of few seconds delay before the light bulb start blinking on a faulty wiring curcuit that needs maintenance.
Modern cars also have some of the worst UI design ever and many don't incorporate it. The push to start buttons are largely disliked by most people with them as it causes the person to have to go through unnecessarily extra effort. The electronic emergency brake is also rather inconvenient because in an event where you actually need it (let's say an engine fire occurs while driving and burns up the brake resivour placed on the firewall [where all the heat goes]), the electronic systems may not be functional. Not to mention having a computer decide whether or not to engage the emergency brake in an emergency is kind of sketchy. Faulty wiring generally doesn't cause the delay, that's either the flasher module or body control module in newer vehicles. Faulty wiring usually is indicated by a rapid flash. We really shouldn't be basic website UI off car UI, nor should we be basing car UI off web UI. Otherwise we'll be living in a world where you need to "start" your website and subscribe to a newsletter in order to use your brakes.
An important piece to the post I believe is building things to be “undoable” as much as possible. This helps negate accidental clicks, and if something is truly destructive a confirmation modal should probably be required
I have ADHD. I have to select the text I use multiple times by double click or triple clicking it. When there's a button, I keep pressing the button, then drag away to not trigger it. I keep doing that with all the buttons. Or a press it, then check if the form is filled correctly, then mouse up when I verified. I guess form buttons are different than a menu button or something like that?
I feel like in any ''full-featured'' UI, act-on-press is only possible in a small number of situations without adding additional logic. On PC, if you have any sort of dragging functionality, you can't do act-on-press without adding some sort of delayed-check to determine whether it was a drag or click(and then you might as well just act-on-release as the responsiveness is already lost)... While mobile would have the same issues with things like scrolling/etc. Every time I interact with a UI that has act-on-press, it often feels like my click is 'disconnected' from the result. When I click then release - and something happens - it feels deliberate; if I click and something is already happening before I ''completed my action'' it feels like something happened automatically. It also helps that this is how most UIs already function(whether that's for good reasons or not). For the argument of ''having shaky hands''/etc, that is something that could be handled via accessibility settings and not something I would use as an argument to make the UI more obtuse for everyone.
The problem with Carmack is that he's the best programmer ever, but that doesn't mean he's a UX specialist. He's reminding me of when Kasparov speaks about politics with the same authority of chess.
Carmack was doing UX before it was even a field in computers. He also did oculus which is more of a test of UX than pretty much any CRUD app people shit out
@@WOLFMOTHER1257 Sorry but no that's just wrong. The job of a UX expert is more so studying user behavior and psychology, not finding the optimal way to implement UI on a technical level. A person can sit in a box for 50 years and develop the best possible theoretical UI, it will still be complete dogshit if it doesn't take into account the reality of what your users expect. Oculus just proves the point, because when Carmack started working on that, there wasn't really an expectation already for how to interact with VR, so he could go wild with his own ideas.
@@seeibe we know from human psychology that everyone wants everything faster. We went from horses to cars, going to the movies to Netflix, downloading songs to Spotify, slow internet to google fiber, 60hz 5ms monitor to 360hz 1 ms, one week to free one day delivery, google and stack overflow to chatgpt. The main way technology improves is by making things faster and faster, which is what the people gravitate towards. People just didn’t think about it when it came to ui, but the moment they do it’ll be the same.
Ad physical buttons: pressed on-off switches act on press to turn on and on release to turn off, and regular leveraged switches (beside not having any release action) simply require more effort to turn. We also sometimes make physical buttons act on hold or require second press for confirmation because it is very often more important to avoid accidental disasters than save a a millisecond.
When there's a delay in the app you open, and it responds to the second time you pressed, opening something within the app, when you didn't mean to press that, and the app didn't even open yet. THAT right there = 😤
I think it would be great to do mouse down for interactive within the page, where the risk of it not being able to be cancelled is a lot smaller that doing it with navigations
Huh, this disproved a couple of doubts I had, sounds like the better way. But I will add that apps/websites should provide a way to undo any accidental click, unfortunately many aren't designed for that.
It doesn't solve the problem of things moving right as you're clicking. I see stuff move right before I tap, but my brain doesn't fully process in time to interrupt the motor cortex queuing up motor signals.
I agree with Carmack with this one and the solution about canceling a misclick (which also was something I was worried about) is quite simple in most cases. - If it is a destructive and irreversible action (or long computation/animation): confirmation dialog (which should already be used in such cases) - Otherwise, allow undo-ing. Could be an actual undo-state that works with ctrl+z, or another button or whatever makes sense. Like a "close" button, a "back", a "decrement" or an "undo". Besides, how frequently do we even misclick? It might be so rare that it makes no sense to not improve everywhere else just for this.
I got a fancy ergo keyboard recently and I've been playing around with hold-tap behaviors, and I agree with him there too. Can't stand the uncertainty when I press a key, I don't understand how people live with homerow mods etc. I tried having some lesser-used peripheral keys as mod-tap, and even that got annoying. I want instant and expected behavior when I press, and changes only happen via layers/modifiers.
If you want to support dragging (e.g. clicking and holding on a link in your browser lets you drag it to the desktop to make a shortcut) then you can't have the action occur on mouse down. But for simple buttons, e.g. in a game UI, I definitely prefer to do the action on mouse down. It depends on the context. Both are useful.
Another example of something that feels really nice when it happens on press, is pulling items from a stack in Terraria. Right-click takes 1 item from the stack, then if you continue holding right-click you get a very satisfying repeat action that slowly increases in speed and pulls more items out of the stack until you release the button. Perfect example of something that would be impossible to do on mouse up.
my brokerage mobile app actually has press activation on the managing order screen so when you scrolling down to the confirm button you can actually accidentally change shit like type of execution, time delays and even position size. it got me by surprise several times before i realized that's not just because i'm bad and put it wrong numbers and options.
One act on release that I like is the macOS system menus. You can either navigate with separate clicks, or click, hold, and release on the menu item. It’s been this way as long as I can remember which would be like OS 6 or something
The underlying input subsystem decides, and it decides so by triggering the touch event after the deadline during which you are allowed to start scrolling, and dropping it otherwise. Let's say the gesture deadline is 30ms, but you hold the button for 200ms, then the release event comes 170ms later than touch. No, it comes much later yet, because there is release debounce which lasts another 30-100ms until the input device driver is certain that a release has occurred. 200 to 300ms of time added. If you were implementing an input layer yourself, you would launch a timer on hardware reported touch and then cancel it if gesture movement has started.
3:00 I believe it's a problem called magic mouse for macs (as you use mac and that mouse). Sensor is quite in front of the mouse so when you want to click on things, it was to drag that thing as mouse moves a bit on click. Super annoying
tempting but would pass it for the web, I have a feeling that the annoyance of not being able to cancel when I want to would outweigh the micro win between the mouse down and up, it doesn't happen that often so I am not sure how exactly would you do a research that would take that in account
I also like to be able to cancel the action by moving away and release it, I guess for critical parts where you need that functionality, keeping track of the last action and undoing it could solve the problem, it makes the code way more complex though, but it's worth it if you already have the framework to undo it.
I think for desktop it makes sense but for phones what counts as a press if it isn't firm? If I am scrolling on the phone and touch pixels while doing so should that count as a press? I feel like press and releasing while still on the same element helps ensure you had an intentional click as opposed to something like Instagram where you can very often accidentally like a bunch of comments. I'm not much of a UI guy so I probably got something wrong. Would be nice if someone has another opinion. edit - Just watched the video and guess you bought up the same issues. Thought I'd comment before just to unbias my thoughts first.
It's funny because this issue comes up in all the Fromsoft games with how they handle both rolling and running with one button. Once you're familiar with that negative edge/on-release behavior, it's not too problematic. But to new players, it simply makes for countless moments where they say "i pressed roll!" but they didn't roll and they died. This causes a similar issue in Escape From Tarkov, where the reload key has multiple uses.. one function is the normal reload action, the other is a quick reload that drops your magazine when you double-tap the reload key. This seems fine on the surface, except that it mandates waiting for a set amount of time on each press of that key to see if another keypress comes in. So even if you have it set to on-press, which you can thankfully in Tarkov, it still waits 300ms by default to see if you press it again to make it a double-press. So, one of the common tips is to either swap the bindings, and mash R any time you want to do a normal reload, because it'll start as soon as that double-press is confirmed.. or rebind the Quick Reload action to some other key, and keep the double-press binding empty (which thankfully does allow the game to do the single-press action instantly -- it only invokes the double-press timer for a given key if that key has a double-press action.. kudos to them for this, or the game would literally be unplayable because *every* action would have a 300ms delay).
I'm going to have to try this out and see if I like it. I suspect I will. Just don't know if it will create a bunch of other issues. But it is a good idea to experiment with for sure. For draggable elements I probably just use onClick, but for non draggable elements I think that is fine. The fact that users can "cancel" a click by dragging afterwards is probably not a use case I would sacrifice better responsiveness for.
one recent trend in gaming is to use hold actions and i can only guess it originated from consoles where you dont have a 10x keyboard to choose your inputs from. so most recent games i played have a double, sometimes tripple assignment for buttons if you count double tapping as well. i would say generally double assignments are to be avoided and maybe a more context sensitive action would be preferable and also better suited for act on press. it all depends on the context of course, but i agree for most cases act on press would be better. but more as a guideline than a rule
Ive tested the on mouse down while scrolling issue on my Android with react native once and it was definetly a problem, maybe the Browser or platform is obscuring the result here
I would hazard a guess that the reason we do it this way (on release) is because that's already how it works on Windows (maybe OSs in general, but I wouldn't know). I don't think most people would notice the difference between the two, and I'm curious to see how it'd change the experience in each setting. P.s.: Going on mouse down some stuff sounds like my new favorite euphemism.
8 місяців тому
You could start a transaction on mousedown, finalize on mouseup, and rollback on mouseleave
I think it's not black or white, this just depends on the part of the UI you are making. For almost all of it, it's great! But when it comes to dangerous actions like "Factory Reset", "Delete" and "Cancel" buttons, it's better to use OnClick. An example is Firefox, most of its menus are OnMouseDown, including changing tabs, but the close button on the tabs is OnClick due to it being an action that is "dangerous" in the sense that it can make you lose work depending on the page you are in.
This comes down to expected behavior of the type of UI element. Act on release might be best for things that commit the changes but for everything else it is fair game.
My video sparked debate on Twitter, and John Carmack left some (really good) comments. Also pointed out that Chrome changes tabs on press, not on "click".
"To perform an action with act-on-release you need to both hit the button, then keep the pointer on target until you perform the release action. If you have a jittery point location, as you do with hand tracking, controllers held away from the body, or old age, this can result in many fail-to-activate cases.
You also want generously sized and spaced buttons, but that is an orthogonal effect."
100% agree. This is very noticeable in menus in VR where you try to click a small button and have to put a lot of effort and focus into keeping the cursor within the bounds of the box for the entire interaction. You feel a noticeable slowdown as you have to steady your hand, stop moving your body, and pay attention to the buttons rather than the content.
"act-on-click/release" is only really valid with a stable cursor and that's antithetical to the VR experience and intent. VR is meant to bring the UI into your world, not pull you out of it to play "aim at the box simulator".
My Firefox on Windows changes tab on mouse press too. Interesting. Don't know why tab changes are on press while other things are generally on release. Although there is a disadvantage to act on press for tabs, sometimes I don't want to open a tab, I want to drag it somewhere else.
Tabs react on Press because there is no probability of regret. We don't submit forms / pay cash by changing tabs. In HTML however, buttons often trigger payments, likes, follows and other sensitive actions that the user may want to cancel mid-way by releasing outside. This is also why most actions on your desktop OS act on Press - while opening applications on desktop require double-click because you could open them accidentally.
@@Nekroido yes I suggest you introduce the concept of “expectations management” to your discussion. Note that before triggering a button, users do not know if a confirmation dialog will exist. We have to deal with their imaginary fears as well.
@@Nekroido these are all layers of reassurance we give them.
Since I was the person that implemented the original OpenGL based keyboard on Quest (originally GearVR), I thought I’d provide some additional context.
John is correct wrt static UI, but I was also one of the people pushing back on his requests to apply this more broadly (such as to nearly everything). Although, I was not the person requesting a study, as the keyboard case was obvious to me ONLY because a text keyboard can easily roll-back characters if you end up holding the key (try holding “n” on the stock iphone keyboard and also note they do act on release).
The main issue is still how often buttons are in scrollable UI. At one point I sent him several screenshots with all scrollable containers tinted red (most of the screen) to illustrate how common it was.
In this video, the impression was given that scrollable containers aren’t a concern, but that was only because the mobile browser ignored your request to act immediately on press/down, and delayed invoking your handler until it could determine you weren’t scrolling. Thus you also weren’t getting the full latency improvements John was advocating for.
In the end, there is some validity to John’s argument but it’s not as simple as just switching things over to press/down events.
* UI frameworks would need to be updated to do a delayed down event while detecting intent-to-scroll
* not-currently-scrollable containers are more common that never-scrollable so they could certainly benefit opportunistically at the cost of minor inconsistency
* any press-and-hold interfaces (think context menus) would need to be replaced or support roll-back logic.
* any drag & drop UI would need similar intent-to-drag delays
Also note - on mobile, intent-to-scroll (or drag) is significantly easier/better than in VR because a touch digitizer samples input at 300-1000hz vs 72-120hz in VR for controllers and significantly less for hand tracking. The precision of your finger is also higher on mobile vs. VR controllers and esp. hand tracking (requiring bigger deadzones and/or delays).
So there you have it - it’s not like the eng at Meta were dumb and didn’t want to have latency improvements, it’s just that we actually have to implement/support all this along with all the edge cases and it’s competing with a million other requests. If it was as trivial as just replacing click with onmousedown, we would have done that years ago.
It seems ideal to act on press and then roll back if the action was unintended for a lot of stuff. Of course, this is not straightforward to implement with our current frameworks.
I hate mobile, its ruining everything! it is the source of the enshittification of everything on and related to the internet.
Thanks for writing it down
@@niamhleeson3522 That is easy to say, but determining if the action was unintended packs a lot of challenges. Even if you define a good enough heuristics to mark the event "unintended" then you can't reliably ensure that this tell of the lack of intention wasn't itself unintended (like few pixels of drag when you only wanted to click). Plus doing all that may take more time then you're trying to save. And the problem isn't necessarily connected to the state of current frameworks. It's just due to human imprecision.
Well... Yeah, mobile browser *is* supposed to delay that. Mobile apps aren't as versatile as desktop ones, so they need to encode different inputs in different ways of tapping on screen. And that's their problem to deal with - on how to treat screen taps as mouse events.
HTMX supports "fetch on press, show on release", which massively cuts back the time it takes to navigate between webpages. It also supports "fetch on hover", which saves even more time, because it usually takes ~100ms before you press after a hover. It does risk fetching too much, like when you quickly swipe your cursor across a menu, but I believe they thought of that too and solved it for most cases.
Very clever approach for stateless/non-destructive updates
This is just a basic preloading strategy. HTMX didn't invent anything.
@@hunterxgthey don’t invent anything new hear, but made it trivial to do something that a neglected by most developers.
Its there in all modern frameworks (Remix, NextJS, Solid etc). Not HTMX specific.
No. Don't just do this everywhere. Understand your game/app. Then apply it where it's needed.
The whole "undoing" a click is HUGE for me, and I'd hate to see it go...
Why though? If you type a command and hit Enter you can't undo, and it's ok. When dialog is closed on Escape press is ok. But closing with mouse on press is not ok?
@@w01dnick Its like keeping your hand on a chess piece even after you've made your move- just in case you re-think it at the last second.
@@Rushil69420 It's just habit. You can't undo Escape/Enter/etc and it's ok.
I so get it, I clicked the like button on your comment and just moved my cursor away without clicking it, it feels so good to have this power
@@w01dnick Right because that irreversibility is associated with mechanical objects that we interact with- like switches and buttons- but not with our hands. We can put down anything we pick up. We can hover our finger over a button and decide not to press it. We can even touch a button and then remove our hand from it. Moving the cursor on screen is more analogous to the physical interactions we have and initiate with our bodies than key-presses are.
Assistive technologies have far better support for the click event than the mousedown event. The click event also includes handlers for keyboard interactions with the space bar or the return key. Please don't forget about accessibility!
Honestly your comment needs to be pinned. Mousedown is not a suitable alternative for click, and suggesting it without further considerations is harmful for accessibility. It also breaks the workflow of heavy keyboard users and tools like Vimium
Just bind both
Came here to say this. As a huge proponent for accessibility, I feel uncomfortable viewing controversial opinions like Carmack's. Oftentimes, you only find what you're looking for, and nothing else. In this, Theo found the responsiveness to be better because that's all he was looking for.
@@hugh5356 exactly.. there is nothing wrong with binding both and cancelling the click event after a mousedown.
@@GottZ Good idea! onMouseDown and onClick together, if onMouseDown is triggered then cancel the onClick. How would you cancel the onClick in that case?
I think it's better to trigger on mouse up most of the time due to the user being able to cancel accidental clicks.
Makes additional sense on mobile/touch screens where a long press is often required to achieve hovering.
A lot of interfaces have things where there's hover effects for info popups or similar, but we lose that on mobile/touchscreens if you active on down rather than up.
Yup.
Mobile: mouse up
Desktop: mouse down
Just out of curiosity, how do you get "accidental clicks" and do you also get them when handling guns?
I wonder if it's feasible to start doing work on mouse down, but only actually commit to it on mouse up. For example, if a user clicks a link, you load the page in the background but only flip to it on mouse up
This. I don't care about any additional features, just let me cancel my mouseclicks.
This not only goes against accessibility, but also user expectation
Imagine 99.9% of websites follow one standard, but you decide to go against it, just so your contact button has a potential saving of ~10ms
I especially hope no one uses on press for important actions, such as confirmations
This is highly context dependent. In most real-time applications, like games (where John Carmack has most of his experience), the user expectation is pretty much always on mouse down. Imagine if you were trying to fight a big scary boss monster and when you go to attack with your sword, you have to release the button before the character swings. Disgusting. Nobody would ever claim "but I wanted the option to not attack the monster sometimes, after half-pressing the button, no fair!"
99.99% of the webpages does UI wrong. The majority of UI should use OnMouseDown with exceptions
Wouldn't on mouse down also be better for accessibility.
If they have jittery hands that means it's very likely for it to go out of the bounds of the box and not activate the click.
@@dandymcgee Highly debatable whether that's true, but even it is, games tend to have garbage ui especially on pc so it's not really a good argument.
@@Utrilus The click event doesn't just mean a literal click. It can also be triggered using the keyboard, and when browsers are used with screen readers they will read clickable events out as clickable like links. If you use a different event like onMouseDown then I think that can only be triggered by an actual pointing device of some sort.
And then there's WCAG, Success Criterion 2.5.2 Pointer Cancellation
If the change can be reverted then it is fine to do it on the down event. That article mentions it in the "Abort or Undo" section.
Although... no, it says it should be on the up event still... then I guess not.
Thank you for the rule drop, I learned something new
@CottidaeSEA WCAG phrasing can be confusing. This SC states that mousedown is only acceptable when it is "essential", i.e. when mouseup is needed for something else. The part about "abort or undo" applies only to mouseup events, basically saying that dragging the mouse off the button and releasing (like the click event) is preferred.
@@joostkersjes4349 Yup, it can be very confusing. As others have written in this thread there is however clear advantages for ALL to be able to cancel accidental clicks
Thank you for citing the standard. This 100%
He is wrong. So many times I've held down on a button, then realized I've changed my mind. So I can release it without clicking.
Exactly. I have come accross some UIs that react on holding down and I always hate it.
exactly...I love Carmack, but he's just simply wrong here.
yeah, agreed
He's not "wrong". He's saying it feels better and he's entirely right.
Are there tradeoffs for that he's not talking about? He mentioned a couple, but also yes.
It's an idea. It doesn't have to be the best everywhere. Keep it in mind for a use case where it might be worth it.
Personally, accessibility compliance is the part I'd care about. I let Radix make this decision for me on a lot of interactions, and I'm not overriding their behaviour to make things happen on mouse down.
For the indecisive people like us, I think onRelease is the way to go xD
There can still be interaction and visual cue to actually pressing a button though. Which I agree.
One thing to mention: on things that should be on release, you can still have a little effect on press. Buttons are like that, to have 4 states: normal, hover, active (aka on pressed, no released) and disabled .... if I remember correctly. Having something like a color change on press would still maintain the feeling of very fast interaction.
as far as styling goes you're right. If my understanding is correct, Carmack's take is a step further than that, like sending a network request or changing the state of the program
@@privateanon7623 Yeah, but you need to see the bigger picture then. There are cases where it should be on release. Like allowing drag-and-drop (which Carmack mentioned).
Whatever happens directly on press has be easily undoable (like on a virtual keyboard) or not that important.
@@Winnetou17 I agree with the principle. Unfortunately that kills accessibility for people prone to accidental clicks, especially those with cognitive disabilities who might not necessarily realize they did. That narrows it down to a small subset of user actions in the non important easily reversible category for me.
the name for "active" is hold
I would add "focus" as a 5th state.
Mixed feelings. I can see the value in some games / high speed situations... But for most work apps etc, it speeds me up to be able to click at the speed of thought, and be able to "undo" the click by dragging off the button before letting go...
That way, each click is less deliberate / more optimistic, and the few extra millisecond before I let go of the button are enough time to hit the brakes on the action if it's wrong.
I feel like with "act on press", I'd need to be way more deliberate with every interaction, and it's stressing me out just thinking about it.
Although to be honest I'm sure this is something one would adjust to quite quickly, and is probably less significant than any of us here is making it out to be.
I feel like every instance of "I made a mistake" is just bad UI design, if it happens often enough then the design is broken.
The real solution for bad UI design is every device have a dedicated ctrl-z button to undo last action.
The best approach is probably somewhere in the middle. while mousedown events would improve mouse UX, high stakes user actions where modal dialogs aren't an option are probably best implemented through keyup type events to allow knowledgeable mouse users to cancel the interaction, even if that userbase is a tiny %
However I still think user accidents should be better handled in UIs. As it stands, proper action cancellation support is nonexistent which is why the alternative of dragging the click outside the box exists in the first place
Edit: Another comment mentioned WCAG success criterion 2.5.2 that ties in nicely with the subject
Word. There is (or was?) also a bug in KDE Plasma where you cannot use some modifiers involving Meta (or Windows, or Command) key in keyboard shortcuts, because it's used to invoke the application menu. Why? Because the action happens on key press, and it won't wait for you pressing other keys.
@@YaroslavFedevych and I always thought KDE was just one large bug that also had a DE attached to it.
"High speed situations" make it sound like you're in one of those cheesy hacker scenes where you say "I'm in" at the end
I really don't get the point of this video, if you cared so massively about quick responsive UI on such small timescales would you not be using keybinds for everything anyway? This whole thing seems like it's massively overstating the issue
I agree with him in a game.
I do not agree with him on the web.
People tend to forget that Carmack is a game developer, do not apply his wisdom outside of games, that does not really work.
You can absolutely do things on press even on the web, increment and decrement quantity in a shopping cart for example. If it is easy to revert the change, go ahead. If not, use the release event.
Really?
I just noticed that switching tabs in Chrome happens on press. But yeah, a link, or a Cancel or Submit button triggering on press? That sounds awful.
Well said. I 100% agree
> If it is easy to revert the change, go ahead
So you apply his wisdom outside of games or no?
This take limits you; you must interrogate wisdom to see if it is applicable in other domains, rather than having the stance that wisdom found in one domain cannot immediately be applied to another - innocent until proven guilty. Most of the time when insights are 'scoped' to the domain, it is abundantly obvious that is the case.
@@seannewell397 Most wisdom *is* scoped to a certain domain. The point is to not just take his words as gospel and do what he says without prior thought.
If you try to use wisdom from basketball and try to apply it to tennis just because both are ball sports, you'll have a hard time. Some things can be similar, but you need to consider everything on a case by case basis regardless. At that point your prior wisdom boils down to a checklist of things you could try, rather than things to take for granted.
This is really good content. I also follow John, didn't see that tweet, and now also got your commentary on it. Thanks for upload!
Navigation on mouse down sucks when you just want to grab a link and drop it into a new tab or a separate window as the url. The same goes for buttons that navigate you with js without being anchors so you also can't middle click / ctrl click them into a new tab that way.
I really like Cormacks advice. I get the point of cancelling clicks, and also about people being used to the current patterns. However many of us would use the Intenet more conciously if there was an immediate action. There might be even better UI expereince invented than what we have today. To those who disagree with Cormack, I have a question. Did you think through how UI needs to be adjusted? Here is something that I suggest browser vendors could give us, no matter what opinion we have on this topic on accessibilty: Let the browser users decide in user settings how the mouse-down event should be applied. Some want an immediate response, some want to keep the ability to be able to cancel the event. Everyone will be happier if we can customize the expierence, and I could think of even other ways to give each one of us a better UI experience than what we have today, if we had more choices. Configure the mouse-down event to acct as a double click, colors, gradients,, form of button, etc. accoustic feedback amd what else..
I love John, and I love that you prefaced this video with some background on why people should listen to him when he talks. I love, even more, that you still thought critically as you listened and went and tried things out for yourself instead of accepting his experience and opinion as fact. Keep up the good work.
It can be annoying though - tiktok uses the ontouchstart trigger for one of its buttons but if you touch it when scrolling, it gets pressed and the scroll is cancelled.
If you're on Tiktok, being annoyed is the least of your problems.
The best option: make it a setting. If some people like act-on-relase, they can use that, anf if they like act-on-press they can use that. A lot of problems can be solved by just introducing a setting. (Yes I know that most people don't bother going into settings, so choosing a right default is good too).
While I do understand his arguments.
I really don't want accidental click when I use my touchpad, cause yeah, if I was unlucky enough to stop using the touchpad with a cursor on an element and have touch to click, damn. retaking control of the cursor without clicking is going to be hard.
Being able to move the cursor OUT of the element before release to avoid clicking have saved me more than a few times.
Also, it's not than phone browser knows to ignore, but that the phone do not send the event to the browser in the first place. at least, it used to be the case on older iphone if I remember correctly
It is still a case on new iPhones, checked just right now. Wonderful feature, Carmack is wrong
The issue here is that 'onclick' means different things for different input types. Touchpads need to be safer, so probably don't want to use a cue that is going to throw up lots of false positives. This shouldn't be an argument for why I should be slowing down waiting for mouseup when I am using a mouse with reliable buttons.
It shouldn't be a UI question at all, it should be a hardware question. What does a 'click' mean for that particular piece of hardware? For a mouse it could perfectly reasonably be considered to be mouse down. For a phone it will be something different, and a touchpad something different again, not to mention tech for accessibility. All a website needs to know is that you clicked on a thing. It should not be dogmatic about what a 'click' is.
I think I disagree for a good chunk of cases because of what Theo mentions at 3:09 : having events happen on mouse-up/release events is a layer of protection against misclicks. I'm more tolerant to unresponsiveness than I am to "hyperresponsiveness" if that makes sense. I think you can get 90% of the feeling of responsiveness by creating a visual acknowledgement of the press event, e.g. changing the color of the button. You can even change the color on hover (if using a mouse), which feels very responsive and telegraphs the consequences of a click.
The phone VR issue (applied to early VR headsets too) was not about fps (though 90+ fps is best for a feeling of presence within the virtual world), but about latency. The world catching up slowly when you turned your head was due to latency between you moving and the system detecting the movement, updating coordinates for the renderer, and sending the image to the screen so that photons could hit your retina. That is a chain of events where latency adds up at each step. It would not matter if you had a 200 fps renderer if the other steps had significant latency.
I thought Carmack denied that he was the one who wrote the fast inverse square root function. AFAIK it's actually unknown who wrote it.
Edit: did mobile always handle onMouseDown correctly? I swear I have unintentionally clicked buttons while scrolling a lot in the past.
same, but i suspect this issue is mostly prominent in horizontal sliders/scroll.
Yeah, scrolling down to the history section of the Wikipedia article shows that William Kahan and K.C. Ng first wrote a paper on the fast inverse square root in 1986, and then Greg Walsh wrote the exact algorithm in the late 80s.
@@JediMB I might be wrong but I think it's not the algo that john is praised for it's the WAY he implemented it in C with the weird address bitshift one liner. Don't quote me on this though. Just thinking out loud
I'm pretty sure mouse/touch actions used to have a ton more issues early on. I remember having to use an entire library just to handle simple interactions confidently. Nice to see it's so intuitive out of the box now.
@@TheBendixSA From what the article said, Carmack has never taken credit for it. It was just speculated that he'd written it after the Q3 code was made public.
If you read the history section, you'll see there's a pretty good timeline of how the algorithm presumably traveled from person to person until someone at 3dfx told Carmack about it.
Was just thinking about this pattern because of several unintentional interactions with the like button on LinkedIn. Was able to cancel with the decades-old OS-level UX of moving away. Act on mouse up is a very good default. For the love of good UX do NOT just started making ALL interactions act on press because you treat the internet as gospel truth.
A me problem: I like to have to option to cancel my click action, if I have the reflex to do so.
A "web" problem: Buttons on the web have this really cool feature that when you focus on it with your keyboard and press spacebar (Enter too, I think), it calls the onclick function. The onmousedown event, on the other hand, it's not called. So you would either be sacrificing accessibility by doing nothing, or give you more work to do to ensure the native behavior still works (listening to keyboard events, checking if it's "spacebar" and if it is, call the onclick function, etc etc etc).
The amount of times ive clicked a button by accident and ive saved myself by holding down left click and dragging ny mouse off of the button is crazy. I actually love that part of it
I think you could get the "best of both worlds" if you have an `onMouseUp` registered to `` that executes an undo on the last operation done in the UI if it is hit, while you have an `onMouseUp` directly on the element that simply cancels event bubbling. Then if you press and hold, then move away before releasing, it reverts whatever that change was but if you press and release then it already started doing that operation on the `onMouseDown` event as Carmack is calling for. This would require that your UI maintains an undo mechanism under the hood, but people are people and make mistakes, so that's *probably* a good idea to have anyway?
Or we could just stop pretending that those few milliseconds are doing anything for you
When the page layout changes from a result of a keydown, I imagine could cause problems. And if we want to mix different types of buttons, we really should have a visual language to tell the user what to expect. In VR UIs I can fully see how keydown events are better, I dont how many times I've missed a button because my hand shaked a bit before I was able to let go of the trigger. Hmm... Why are we using the pistol grip for VR cursor actions anyway? Is that really the most stable way? Could a reverse-flashlight-like grip be more stable than a pistol grip to avoid click-shaking?
Having to hold your hand PERFECTLY STILL while you click on UI elements in VR is the worst
I'd hate this on "send"/"confirm" buttons, where I might decide to NOT do that at the last second, and I can just drag my mouse away to cancel it. App devs, Carmack is a legend, but please don't listen to him here.
As a webdev, I'll never do act on press. This is simply anti-user practice
Have you missed this part: "*Whenever possible*, you should "do the thing" when you get the press event (...)" ? That implies a nuance. Send/confirm/commit buttons aren't often interacted with, and as such wouldn't affect the experience if it would be set to act-on-release.
exactly!
You are just punting the problem of bad UI on this. Good UI does not require mouse acrobatics to cancel send, it simply lets you undo send.
@@alexandr0id OK, you've sent an email. How on earth are you going to "un-send" it? It's already gone.
It has nothing to do with good UI or bad UI, some actions just cannot be undone. And it is good to have some way to change your mind after you accidentally click a button that does them.
Somehow I get the feeling this breaks accessibility unintentionally. It's interesting that it fired on a touch event, maybe mobile logic lets it work if it's the only event specified. Keyboard navigation is another concern.
That said, it does feel nicer to fire on a down event.
If one has jittery hands wouldn't that mean they would fail to click more often if it's not on touch event? A lot more chances to move out of bounds.
@@Utrilus @Utrilus The click event doesn't just mean a literal click. It can also be triggered using the keyboard, and when browsers are used with screen readers they will read clickable events out as clickable like links. If you use a different event like onMouseDown then I think that can only be triggered by an actual pointing device of some sort.
I think that for sensitive or potentially destructive operations, buttons should act on release. Many times I have pressed a button to later think again and move the mouse over to cancel :p
True, but in that case they should trigger a confirm box imo
@@pianochess1882 Great, now you have two "responsive" buttons and confirmation boxes everywhere. Either way for sensitive or destructive operation there should always be a confirmation box. This is just a bad idea.
@@pianochess1882 every submit button, every link click, every next button now comes with an "are you sure". You have now doubled the amount of clicks to navigate the internet, and caused people to reposition their mouse / hand / keyboard focus / etc, to the center of the page, to click ok... which had better be a browser standard, because it would be an easy dark pattern for a company to swap them around from page to page, and 99% of the population would just not notice.
@@Xomps might as well make the one in the confirm box "mouse-up", confirm boxes everywhere probably are a good idea though anyways, right?
If buttons _sometimes_ act on release (and I agree that they should), they should _always_ act on release so as not to baffle the user with their inconsistent behaviour. There can be exceptions if they are clearly conveyed, but it's rarely necessary that buttons trigger some action on the down press, whereas sensitive and/or destructive operations happen all the time.
I don't know about other areas, but on the web, "Act on Release" is a must, users must be able to cancel a click or a touch on a button or a link.
It seems a huge number of people in the comments got the impression that John Carmack and Theo are advocating for using Act on Press for literally everything. I don't think that was ever implied at all - Its clear that the point is that it should be used for SOME things such as keyboards where people expect responsiveness or other things that have a "switch-like" behavior. Obviously use your judgement as to where its appropriate.
Sure, but that's not what Carmack wrote, was it? The amount of developers who believe design is about absolutist auto-anthropological self-report is horrifying; and based on this tweet, I wouldn't put it past Carmack either.
I like that he's initiating the discussion, but I don't like this tweet.
Guys he's mostly talking about VR, not websites. For VR I think it makes ton of sense.
Oh no, please don’t! On release is a learned behavior, people know they can still drag their mouse away from the button before releasing to prevent the action to be called. Please don’t take this away from us! For most interactions people wouldn’t even notice, because when working in an app you don’t look at the counter. Most people here are probably working on apps where there are much bigger performance improvements can be made without breaking user expectations. Most people aren’t working on a keyboard on a VR headset, they are working on some random banking app that talks to some legacy backend and every page takes 15 seconds to load. But now they saved two full frames and all they had to do was to break 40 years of learned behavior!
Those performance improvements will never be made. We have years of history now to see that websites get SLOWER, not faster.
06:52 there are virtual keyboards like onboard that are on release (by default) because you can hold to open character selector
Are there any on-screen phone keyboards that operate on touch rather than release? I don't think I've ever used any that do.
I don't get the argument that onPress feels more responsive. I'm sitting here pressing random onRelease buttons right now and they feel perfectly responsive to me.
I much prefer being able to correct my mistake by moving my pointer/finger away before releasing than the extra 10ms or whatever that I don't even notice.
Maybe in a high-paced game I would notice. For example, I can see the argument that a gun should shoot on the _press_ of a mouse click, rather than on release. But for most regular 2D UI buttons I think onRelease is the way to go.
I went through this conundrum recently when building some TV apps (with a Netflix-like 'Row/List' UI) where the interaction is using a remote control. I went with the 'press' in the end. It just felt better.
Worth also looking at using the 'PointerEvent' (onpointerdown) rather than the mouse events. To help cater for touch and stylus etc. controls, where onclick would have handled them.
“Act On Press” - John Carmack's Bad Take On UI
It’s a tool to keep in your pocket and be aware of, but… I remember 10-15yrs ago also going “Oh wow, way faster on mouse down vs. click” and then also pretty swiftly learning my lesson about why it doesn’t make sense to always do it all the time.
And under what context is that? everyone acts as if he was suggesting it to be implemented on every kind of UI yet his beef might be the exact same issue but inverse, that nowadays everyone and their mom implement press and release because programming for mobile rotted their brain.
@@teresashinkansen9402came here to say this.
John mentions all the use cases and arguments for when to use it and when not to use it.
It's also funny to see people disagree with someone who is infinitely better at programming and user experience than most of is will ever be without fully listening to his argument.
It's just "guy on internet said something that goes against what I learn in school." And they flip out
I use "release miss" many times to cancel click, probably some "unrecoverable" operations should use "up" event but all simple operations should use "down"
The cost of a mistake can sometimes be too high. The ability to undo an action is a crucial aspect of good user experience, allowing users to correct their errors.
It depends on what is more important, speed (or time accuracy) or avoiding accidental clicks. You can see this with Google's stopwatch. The start/stop button acts on press, the reset button acts on release. And it makes sense. That's also probably the reason why act on press is more common in games.
This might be okay for states that are temporary, however, I see a lot of alternate considerations like WCAG.
I certainly want the ability to opt out of buying something after mouse press by moving away from the button as many others would.
So we get the best of both worlds, how about we load the state during on mouse down but don’t commit the change until the click is registered on the element; this would be especially useful for making fetching data from the server more seamless.
Seems like a good idea! Feel like it would need a better implemtation by frameworks to make it easier/feasible to do.
oh no thinking about VR made me motion-sick
I'm more in the on-release camp. So many times I do that "click - oops! - drag off the control - release" thing. For FPS games, sure, act upon press. For most UIs, nope.
This should be a user-specified OS setting. Users should be able to choose which event they prefer to count as "click", and applications (including browsers) should hook-in to this OS setting.
Please don't. There's a reason why he can't get traction for his idea. UI developers know more about how UI works than a game developer.
Users do not perceive acting on mouse up to be slow. And the only users who unintentionally move the mouse between mousedown and mouseup are the ones with a shake and thus are more likely to misclick. They need the option to opt out of a click.
Then there's mobile, where touching the screen can be a scroll attempt or even an errant press.
People have learned that you move the mouse to cancel a click, and slide your finger to cancel a touch. Don't mess with people's intuition just to create a more "responsive" experience they won't notice.
There's a reason why UI developers will intentionally add delay. Outside of games or other fast action situations, people want a more deliberate pace. They don't even perceive it as lag.
I mostly agree with you but did you even watch the video? He did mention all these points
@@Logan9312 Well, no. I watched the video long enough to hear the original idea, and thought it didn't make sense, and thus had no reason to continue. I was going to say nothing, but then I saw the description where he says he genuinely plans to change how he codes.
I then responded to that.
"UI developers know more about how UI works than a game developer."
Appeal to authority fallacy, not an argument.
"Users do not perceive acting on mouse up to be slow."
I am a user and I perceive button down to be faster than button up (because it objectively is and my nervous system works). Debunked.
"the only users who unintentionally move the mouse between mousedown and mouseup are the ones with a shake and thus are more likely to misclick. They need the option to opt out of a click. "
They cannot control when they press the button, but they CAN control when they let go of the button? Not plausible. You're making it up.
"Then there's mobile, where touching the screen can be a scroll attempt or even an errant press."
This is the one legitimate argument for button up. The fact that scrolling sucks on mobile devices. However mobile users don't use a mouse and your software should be able to tell the difference between a mouse click and a touch event.
"People have learned that you move the mouse to cancel a click, and slide your finger to cancel a touch."
No, this is historical revisionism. Before mobile devices became the target platform for all UI design canceling a click was not a thing any user would expect or attempt. Most interfaces reacted when you pressed down. If users come with this expectation now it's because of their time using touch screen devices or because of their time using websites designed for phones, with mouse interaction being an afterthought for the developers. Step 1: You make the entire internet feel like a phone app. Step 2: Users start to expect this sort of design. Step 3: You justify that you have to keep doing things this way because of step 2.
@@forasago No. That's not the appeal to authority fallacy. That specifically refers to "cit[ing] an authority figure who is not qualified to make reliable claims about the topic at hand." It is the game designer describing UI whbis the false authority.
Besides, I go on to explain why using more reasoning. It is not actually a good practice to split up people's points like that. It can misconstrue the overarching meaning.
People do expect inputs to change on release. People do back out of misclicks and mis-taps. Changing that in pursuit of a speed increase can be disconcerting and actually make things feel cheap.
Games need fast responses primarily so they have the time to set up smooth animation. You need a frame or two, yet you want to feel responsive.
In most other software contexts speed is not required. Developers have for a long time chosen to actually slow things down. Why do you think Windows takes 400 milliseconds to show a menu?
@@ZipplyZane Fair enough, the fallacy I was looking for was Argument from authority. You're saying these established practices in UI design are the best we can have because UI designers believe so, and they are experts on this matter. You should be able to see how this is fallacious because it would mean that any time there is an industry standard it would have to be the best possible way to do things. The experts you're citing are the same people who created this standard. Also they believed in something else earlier and will likely change their minds again in the future. Yet what they think of as best practices right now is best? Obviously not an argument.
"Why do you think Windows takes 400 milliseconds to show a menu?"
Same reason Windows or a browser takes up a GB of RAM before you do anything with it nowadays. Bloat. Negligence.
Sometimes I accidentally press something and I hate not being able to drag away while holding to prevent it from happening
For the car example at 8:00. Modern cars don't use a turn key anymore, it's a push button to start the car, and that push button is not "on press", it's "on hold" along with other "if" conditions like holding down the brake pedal, or checking some sensors if mechanical damage consequences are detected.
The handbrake on modern cars is no longer a lever pulling a steel cable, it's an electronic button that you hold for a few seconds while the computer go through its "if" conditions, like the brake will act differently depending if parked or driving at high speed. If you mess too much with the electronic parking brake in a too short period of time, it will fall into standby mode.
The turn signal lever is a toggle switch letting electric current through, so you'd think that's kind of "on press", well not always since some drivers are complaining of few seconds delay before the light bulb start blinking on a faulty wiring curcuit that needs maintenance.
Modern cars also have some of the worst UI design ever and many don't incorporate it. The push to start buttons are largely disliked by most people with them as it causes the person to have to go through unnecessarily extra effort.
The electronic emergency brake is also rather inconvenient because in an event where you actually need it (let's say an engine fire occurs while driving and burns up the brake resivour placed on the firewall [where all the heat goes]), the electronic systems may not be functional. Not to mention having a computer decide whether or not to engage the emergency brake in an emergency is kind of sketchy.
Faulty wiring generally doesn't cause the delay, that's either the flasher module or body control module in newer vehicles. Faulty wiring usually is indicated by a rapid flash.
We really shouldn't be basic website UI off car UI, nor should we be basing car UI off web UI. Otherwise we'll be living in a world where you need to "start" your website and subscribe to a newsletter in order to use your brakes.
OnPress by default. On release for heavy, possibly destructive, hard to cancel/undo operations.
Can’t tell you how many times I’ve regret-clicked and click cancellation has saved my bacon. 🥓
An important piece to the post I believe is building things to be “undoable” as much as possible. This helps negate accidental clicks, and if something is truly destructive a confirmation modal should probably be required
I have ADHD. I have to select the text I use multiple times by double click or triple clicking it. When there's a button, I keep pressing the button, then drag away to not trigger it. I keep doing that with all the buttons. Or a press it, then check if the form is filled correctly, then mouse up when I verified.
I guess form buttons are different than a menu button or something like that?
Glad it’s not just me doing that 😂
I feel like in any ''full-featured'' UI, act-on-press is only possible in a small number of situations without adding additional logic. On PC, if you have any sort of dragging functionality, you can't do act-on-press without adding some sort of delayed-check to determine whether it was a drag or click(and then you might as well just act-on-release as the responsiveness is already lost)... While mobile would have the same issues with things like scrolling/etc.
Every time I interact with a UI that has act-on-press, it often feels like my click is 'disconnected' from the result. When I click then release - and something happens - it feels deliberate; if I click and something is already happening before I ''completed my action'' it feels like something happened automatically. It also helps that this is how most UIs already function(whether that's for good reasons or not).
For the argument of ''having shaky hands''/etc, that is something that could be handled via accessibility settings and not something I would use as an argument to make the UI more obtuse for everyone.
The problem with Carmack is that he's the best programmer ever, but that doesn't mean he's a UX specialist. He's reminding me of when Kasparov speaks about politics with the same authority of chess.
Carmack was doing UX before it was even a field in computers. He also did oculus which is more of a test of UX than pretty much any CRUD app people shit out
@@WOLFMOTHER1257 Sorry but no that's just wrong. The job of a UX expert is more so studying user behavior and psychology, not finding the optimal way to implement UI on a technical level. A person can sit in a box for 50 years and develop the best possible theoretical UI, it will still be complete dogshit if it doesn't take into account the reality of what your users expect. Oculus just proves the point, because when Carmack started working on that, there wasn't really an expectation already for how to interact with VR, so he could go wild with his own ideas.
@@seeibe we know from human psychology that everyone wants everything faster. We went from horses to cars, going to the movies to Netflix, downloading songs to Spotify, slow internet to google fiber, 60hz 5ms monitor to 360hz 1 ms, one week to free one day delivery, google and stack overflow to chatgpt. The main way technology improves is by making things faster and faster, which is what the people gravitate towards. People just didn’t think about it when it came to ui, but the moment they do it’ll be the same.
So happy to see that not everyone lost their mind. That dude should never be allowed to touch design again.
Ad physical buttons: pressed on-off switches act on press to turn on and on release to turn off, and regular leveraged switches (beside not having any release action) simply require more effort to turn. We also sometimes make physical buttons act on hold or require second press for confirmation because it is very often more important to avoid accidental disasters than save a a millisecond.
The Google store uses on mouse down and I had it miss fire twice when I scroll. So on heavier pages it does interfere with scrolling.
On press for navigation and other non-sending actions, on click for submitting should be a fine compromise.
moving forward with this is a good idea, it will teach people to watch what they click before they click it
Thx for reading "less" as "fewer" correctly 🤓👌
The problem with onmousedown is it listens on any mousclick (left, right, scroll wheel click etc.)
When there's a delay in the app you open, and it responds to the second time you pressed, opening something within the app, when you didn't mean to press that, and the app didn't even open yet. THAT right there = 😤
I think it would be great to do mouse down for interactive within the page, where the risk of it not being able to be cancelled is a lot smaller that doing it with navigations
Huh, this disproved a couple of doubts I had, sounds like the better way. But I will add that apps/websites should provide a way to undo any accidental click, unfortunately many aren't designed for that.
It doesn't solve the problem of things moving right as you're clicking. I see stuff move right before I tap, but my brain doesn't fully process in time to interrupt the motor cortex queuing up motor signals.
What about sliders? When I use sliders I always expect the release to be when the value is captured.
I just went and onMouseDown'd something and it felt like precognition.
don't take away my ability to overthink a click before i actually commit to it 😭
I agree with Carmack with this one and the solution about canceling a misclick (which also was something I was worried about) is quite simple in most cases.
- If it is a destructive and irreversible action (or long computation/animation): confirmation dialog (which should already be used in such cases)
- Otherwise, allow undo-ing. Could be an actual undo-state that works with ctrl+z, or another button or whatever makes sense. Like a "close" button, a "back", a "decrement" or an "undo".
Besides, how frequently do we even misclick? It might be so rare that it makes no sense to not improve everywhere else just for this.
I got a fancy ergo keyboard recently and I've been playing around with hold-tap behaviors, and I agree with him there too. Can't stand the uncertainty when I press a key, I don't understand how people live with homerow mods etc. I tried having some lesser-used peripheral keys as mod-tap, and even that got annoying. I want instant and expected behavior when I press, and changes only happen via layers/modifiers.
THIS IS THE TYPE OF CONTENT I SUBSCRIBE FOR! Easy to implement super helpful tips that I cant get anywhere else!
If you want to support dragging (e.g. clicking and holding on a link in your browser lets you drag it to the desktop to make a shortcut) then you can't have the action occur on mouse down. But for simple buttons, e.g. in a game UI, I definitely prefer to do the action on mouse down. It depends on the context. Both are useful.
Another example of something that feels really nice when it happens on press, is pulling items from a stack in Terraria. Right-click takes 1 item from the stack, then if you continue holding right-click you get a very satisfying repeat action that slowly increases in speed and pulls more items out of the stack until you release the button. Perfect example of something that would be impossible to do on mouse up.
But a button that has to do something on onMouseDown will do that even if we do a right click on that button. So how would you fix that?
my brokerage mobile app actually has press activation on the managing order screen so when you scrolling down to the confirm button you can actually accidentally change shit like type of execution, time delays and even position size. it got me by surprise several times before i realized that's not just because i'm bad and put it wrong numbers and options.
One act on release that I like is the macOS system menus. You can either navigate with separate clicks, or click, hold, and release on the menu item. It’s been this way as long as I can remember which would be like OS 6 or something
Azure uses it and it always surprises me when it triggers sooner than I expected
Using SDL you can capture button down / up events.. makes things super flexible
For me the thing is that the ability to move mouse away and release when I misclicked is way more important than the delay in the interaction.
Getting this sort of info at me, which I'd likely otherwise miss, is why I watch Theo's videos.
Except you need to decide if user pressed the button or started the scrolling/gesture. So if you act on the press, how would you decide?
The underlying input subsystem decides, and it decides so by triggering the touch event after the deadline during which you are allowed to start scrolling, and dropping it otherwise.
Let's say the gesture deadline is 30ms, but you hold the button for 200ms, then the release event comes 170ms later than touch. No, it comes much later yet, because there is release debounce which lasts another 30-100ms until the input device driver is certain that a release has occurred. 200 to 300ms of time added.
If you were implementing an input layer yourself, you would launch a timer on hardware reported touch and then cancel it if gesture movement has started.
I've been doing that for buttons where the actions is not too commiting
3:00 I believe it's a problem called magic mouse for macs (as you use mac and that mouse). Sensor is quite in front of the mouse so when you want to click on things, it was to drag that thing as mouse moves a bit on click. Super annoying
tempting but would pass it for the web, I have a feeling that the annoyance of not being able to cancel when I want to would outweigh the micro win between the mouse down and up, it doesn't happen that often so I am not sure how exactly would you do a research that would take that in account
also when I mouse down a link and hold it, it becomes draggable and I can drag it to a new tab, that wouldn't work with the act on press pattern
He is wrong. I dont know how many times Ive accidentally pressed something and I didnt want to.
What about hyperlink anchors ?
I also like to be able to cancel the action by moving away and release it, I guess for critical parts where you need that functionality, keeping track of the last action and undoing it could solve the problem, it makes the code way more complex though, but it's worth it if you already have the framework to undo it.
Emergency button stops only works on click off
4:19 that’s my only concern, but I guess you can always use other design standards like confirmation modals or something similar perhaps?
How did it happen that we did not adopt act on press for mouse buttons when that is what we have always expected for keyboards ?
I think for desktop it makes sense but for phones what counts as a press if it isn't firm? If I am scrolling on the phone and touch pixels while doing so should that count as a press?
I feel like press and releasing while still on the same element helps ensure you had an intentional click as opposed to something like Instagram where you can very often accidentally like a bunch of comments.
I'm not much of a UI guy so I probably got something wrong. Would be nice if someone has another opinion.
edit - Just watched the video and guess you bought up the same issues. Thought I'd comment before just to unbias my thoughts first.
All "where is the data" arguments must immediately be responded to with Comic Agile #285.
It's funny because this issue comes up in all the Fromsoft games with how they handle both rolling and running with one button. Once you're familiar with that negative edge/on-release behavior, it's not too problematic. But to new players, it simply makes for countless moments where they say "i pressed roll!" but they didn't roll and they died.
This causes a similar issue in Escape From Tarkov, where the reload key has multiple uses.. one function is the normal reload action, the other is a quick reload that drops your magazine when you double-tap the reload key. This seems fine on the surface, except that it mandates waiting for a set amount of time on each press of that key to see if another keypress comes in. So even if you have it set to on-press, which you can thankfully in Tarkov, it still waits 300ms by default to see if you press it again to make it a double-press. So, one of the common tips is to either swap the bindings, and mash R any time you want to do a normal reload, because it'll start as soon as that double-press is confirmed.. or rebind the Quick Reload action to some other key, and keep the double-press binding empty (which thankfully does allow the game to do the single-press action instantly -- it only invokes the double-press timer for a given key if that key has a double-press action.. kudos to them for this, or the game would literally be unplayable because *every* action would have a 300ms delay).
I'm going to have to try this out and see if I like it. I suspect I will. Just don't know if it will create a bunch of other issues. But it is a good idea to experiment with for sure. For draggable elements I probably just use onClick, but for non draggable elements I think that is fine. The fact that users can "cancel" a click by dragging afterwards is probably not a use case I would sacrifice better responsiveness for.
one recent trend in gaming is to use hold actions and i can only guess it originated from consoles where you dont have a 10x keyboard to choose your inputs from. so most recent games i played have a double, sometimes tripple assignment for buttons if you count double tapping as well. i would say generally double assignments are to be avoided and maybe a more context sensitive action would be preferable and also better suited for act on press. it all depends on the context of course, but i agree for most cases act on press would be better. but more as a guideline than a rule
On-release buttons sometimes can be found in non-computer-keyboard pushbutton UIs on equipment. Very irritating most of the time.
Ive tested the on mouse down while scrolling issue on my Android with react native once and it was definetly a problem, maybe the Browser or platform is obscuring the result here
I would hazard a guess that the reason we do it this way (on release) is because that's already how it works on Windows (maybe OSs in general, but I wouldn't know). I don't think most people would notice the difference between the two, and I'm curious to see how it'd change the experience in each setting.
P.s.: Going on mouse down some stuff sounds like my new favorite euphemism.
You could start a transaction on mousedown, finalize on mouseup, and rollback on mouseleave
I think it's not black or white, this just depends on the part of the UI you are making.
For almost all of it, it's great! But when it comes to dangerous actions like "Factory Reset", "Delete" and "Cancel" buttons, it's better to use OnClick.
An example is Firefox, most of its menus are OnMouseDown, including changing tabs, but the close button on the tabs is OnClick due to it being an action that is "dangerous" in the sense that it can make you lose work depending on the page you are in.
This comes down to expected behavior of the type of UI element.
Act on release might be best for things that commit the changes but for everything else it is fair game.