Act on Press

https://twitter.com/ID_AA_Carmack/status/1787850053912064005

by uxcolumbo • 2 years ago

154 124 2 years ago

twitter.com

uxcolumbo4• 2 years ago

Here is the tweet:

------

Act on press

This is a UI design hill I will die on, and it dismays me how often and hard I have had to fight for it.

Almost all interaction methods have a “press” and “release” event associated with them. Whenever possible, you should “do the thing” when you get the press event instead of waiting for the release event, because it makes the interaction feel substantially more responsive, and it reduces user errors by not allowing the focus to slide out of the hot box between press and release.

Even a “ballistic tap”, where your finger is intentionally bouncing off the button or touch surface, involves several tens of milliseconds delay between the press and release, and most button presses have well over a hundred ms dwell time. There is a delight in interfaces that feel like they respond instantly to your wishes, and the benefit to every single user is often more important than additional niche features.

Game developers, with simple UI toolkits, tend to get this right more often, but “sophisticated” app designers will often fight hard against it because it is mostly incompatible with options like interactive touch scrolling views, long press menus, and drag and drop.

Being able to drag scroll a web page or view with interactive controls in it is here to stay, and nets out way better than having to use a separate scroll bar, but there are still tons of fixed position controls that should act on press, and it is good UI design to favor them when possible.

In the early days of mobile VR, the system keyboard was a dedicated little OpenGL app that responded instantly. With full internationalization it became prudent to turn it into a conventional Android app, but the default act-on-release button behavior made it feel noticeably crappier. The design team resisted a push to change it, and insisted on commissioning a user study, which is a corporate politics ploy to bury something. I was irritated at how they tried to use leading questions and tasks, but It still came back one of the clearest slam-dunks I have seen for user testing – objectively less typos, expressed preference, and interview comments about the act-on-press version feeling “crisper” and “more responsive”.

So, I won that one, but the remaining times I brought it up for other interfaces, I did not, and you still see act-on-release throughout the Meta VR system interfaces.

taeric6• 2 years ago

I confess this tweet surprised me. I can't think of many games (any?) that only act on release. There are plenty that have release activation. Famously there is the video of Mario 64 using half an A press. I don't know of many that only do something on release, though. What games do this?

I am not at all surprised to know that Android had some questionable default behaviors.

Sniffnoy• 2 years ago

Nitpicking, the "half an A press" terminology refers to getting effects from having A held, not from the release (I could nitpick this example more but I'll stop there); something like Street Fighter might be a better example for an effect specifically from releasing.

taeric6• 2 years ago

Fair nitpick, I think. Many games have "charge" moves that do something on release. Mega Man in later versions come to mind. Any game that lets you hold on to walls and such. Mario would be what comes to mind for those, as you would hold on to walls until you let go of the button.

Again, fair nitpick.

pavlov• 2 years ago

He’s talking about GUIs, not games.

It’s standard for the “click” event to get sent on mouse button release. I think it’s been this way ever since the 1980s.

taeric6• 2 years ago

Fair, I think. Most toolkits usually have a down and release event, with click being a shortcut on those. Has an odd parallel/collision with keypresses, as those also have repeat events, often? I don't know any system that has click repeats as a configured thing.

TheAceOfHearts• 2 years ago

In MOBAs like Heroes of the Storm you can configure your hotkeys in 3 modes: on-press, on-release, and normal.

I use on-release with abilities that require careful targeting, which causes the press action to activate targeting with the ability firing on release. You can dismiss the ability by right-clicking too. This is usually more reliable than normal targeting since the game requires very quick interactions.

arh68• 2 years ago

Any idea how popular each is? Just curious.

It's the same in League, they're just called quick cast & quick cast w/ indicator. And normal cast, but I think nobody uses it. I feel like on-release (w/ indicator) is more popular when people can choose, but maybe not.

I like that it's configurable. Perhaps most importantly, some abilities are hardcoded to use the sensible option when only one makes sense.

phailhaus• 2 years ago

He specifically does not call out games:

Game developers, with simple UI toolkits, tend to get this right more often

taeric6• 2 years ago

Totally fair. I should have reworded. How many frameworks only send clicks over and don't have both down/up events included? Key presses usually have a repeat event?

We don't usually go so far as MIDI does with speed of press and such, but that is a fairly old concept.

numpad02• 2 years ago

I wrote in a different stand alone comment but I think this has to do with button down being just unreliable for mechanical buttons. The system always has to do some debouncing, so most GUI systems only listens to button up, and only in games the down event is used with extra caution.

taeric6• 2 years ago

Debouncing was literally several classes in my college years, as I recall. Can definitely be more complicated, but I find the anecdote of a team trying to insist that it isn't a better experience mind blowing.

Granted, just the other day, I found that in GMail key repeat events are slow as heck for some reason. Made holding backspace to delete a sentence annoying.

kalkr• 2 years ago

"Devil Daggers" has an action on release scheme, you play as a floating hand that shoots daggers with two firing modes, a "shotgun" like dagger blast, and a "stream" of individual daggers. The first, which you activate by clicking then quickly releasing, does a lot of damage, but suffers from a cool-down. the latter, which you get by holding for a certain amount of time, is good if you need constant damage.

Interestingly, the game programmed this behavior by moving the position of the hand. When you press LMB, your hand begins traveling forward. If it reaches a certain position, it will start the dagger stream. If you let go before it gets to that spot, it activates the "shotgun" and teleports the hand backward to naturally introduce a cool-down, returning to the neutral position after some time.

People figured out that, because holding the mouse down moves the hand forward, if you shotgun then re-hold the mouse button, your shotgun cool-down is much lower. Most runs will do this because it allows you to do the most damage in the quickest time, but initially learning it is really strange because you don't expect the action to be on release.

https://www.youtube.com/watch?v=JNrCdNFAYW4

eru8• 2 years ago

Famously there is the video of Mario 64 using half an A press.

The release doesn't really do much, though? (Does it do anything, outside of stopping swimming?)

taeric6• 2 years ago

Yeah, I meant it more as evidence that things aren't limited to on press. That said, I think the other comments were clear that I missed the point that games get this right, by and large. :D

N_A_T_E• 2 years ago

Institutional UI/UX departments always seem to overthink this stuff and get it wrong. I would love it if there was a rulebook we could reference so this sort of thing isn't always a battle.

Kiro3• 2 years ago

Game developers, with simple UI toolkits, tend to get this right more often

In almost all games I play there is an inventory and a hotbar and the way you assign items to the hotbar is by dragging it. To use the item from the inventory you release the button without dragging. How else could this be done?

constantcrying5• 2 years ago

I don't think I have ever seen auch a system. Seems incredibly weird, as you can't reliably distinguish between the two. A user moving his mouse during a click is it a drag? Or is an activation? That is very hard to distinguish.

In my experience games with auch an inventory system have e.g. a double click for use.

(Also, this is irrelevant to his point I think.)

gknoy• 2 years ago

World of Warcraft action bars are this way by default, and I imagine other MMOs do as well. Drag a spell onto the bar to be able to use it more easily. Click it (or, ideally, press an associated hotkey), and it casts the spell or uses the item. Drag the button, and it will make it so that you are again moving the spell around to put it on a different action bar slot (or remove it).

Some of them make it so that you have to hold shift when dragging, and that would play nicely with act-on-press, since you already know that the shift-click indicates the start of a drag.

squigz• 2 years ago

Dragging items to a hotbar is very common. Pretty sure Minecraft does it. Black Desert does it. I think Barotrauma does it. Space Engineers, Terraria... I could keep scrolling through my Steam library but I think I made my point.

Kiro3• 2 years ago

The problem you're describing is only a problem with Act on Press, which is why it's normally Act on Release, so I don't understand how it's irrelevant to his point.

I'm not sure I've ever seen a game which requires a double click for use. Do you have any examples?

uxcolumbo4• 2 years ago

I'm not sure this should be applicable to critical actions, like completing a bank transfer, buying shares, etc.

For non critical actions where there is an easy undo - yes go ahead, e.g. in his example for an on-screen keyboard it makes sense. If you make a mistake you can easily undo it. But not when it comes to completing a major transaction.

constantcrying5• 2 years ago

Why? If it is critical give the user a confirmation screen where he can review his order.

That is, much, mich better than relying on the user realizing his mistakes 50% into the click and then figuring out how to get the computer to not continue.

uxcolumbo4• 2 years ago

I'm speaking from personal experience, I don't have quantitative data. If I'm on a review / confirmation screen I would prefer the action to be triggered on release - that's how other forms work and I gotten used to it working that way. Getting another popup to confirm the action would be annoying.

For other actions like adding stuff to a basket, increasing number of items etc, yes use on press.

constantcrying5• 2 years ago

Rather obvious I would say.

I think the reason why UI designers move away from this is because on touch devices, touches have a double meaning, a short and long tap do different things, so you have to act on release.

wk_end• 2 years ago

UIs have worked this way since, basically, the very beginning - long before touch devices were a consideration.

ibejoeb• 2 years ago

I'm sure there are many contexts in which this is a good idea.

For many others, though, I like to be able to press, move whatever pointing device I'm using from the hot zone, and release to cancel the action. It's like holding the chess piece.

5424582• 2 years ago

The Web Content Accessibility Guidelines agree with you. Doing things on mousedown is considered an accessibility issue.

https://www.w3.org/WAI/WCAG21/Understanding/pointer-cancella...

abtinf5• 2 years ago

That document gives quite a bit of latitude in appropriate implementation, including Carmack's preference for act-on-press with undo.

casperb• 2 years ago

I use this quite a lot as well. Holding the merge button on GitHub, while thinking it through one more time.

I could get used to act on press, but this is my current muscle memory after 30 years of computers.

PlunderBunny• 2 years ago

(Physical button, but…) There are many reasons why I dislike the Apple Touch Bar, but the most important one was that – as a software developer – I’m used to resting my finger on the F5 button.

ZiiS• 2 years ago

Odd example as chess is often played with rules that forces you to move a piece you touch.

Retr0id2• 2 years ago

It is, and as an amateur player I find it a very frustrating rule to play by.

eviks3• 2 years ago

That's what makes the example good as you might remember the pain from this rule being enforced when you've touched n mistake

8372049• 2 years ago

Yes, but you can at least move it elsewhere as long as you haven't let go.

dusted2• 2 years ago

It's a perfect example, that rule is not there to make it easier to play the game, it's there to make it harder.

This is common in lots of sports, think about pistol shooting, you're supposed to shoot one handed, arm straight, shoulder to target. That's NOT the best way to shoot if your goal is to hit the target, it's the best way to shoot if you want a challenge.

abtinf5• 2 years ago

https://twitter.com/ID_AA_Carmack/status/1787853145197904063

aaomidi2• 2 years ago

Yeah if that memory sticks around, then its probably a core/foundational one.

John is just outright wrong.

jagged-chisel• 2 years ago

While my own habits agree with you, there’s a gold nugget in the replies to address accidents:

Just do it, but allow it to be un-done.

No matter what the action. This might mean rearchitecting that interactive flow. It might even need deeper rearchitecting for other tasks. But “allow undo” should definitely be an option for “action on press” flows.

eterm• 2 years ago

See also "Never use a warning" (2007): https://alistapart.com/article/neveruseawarning/

pseudalopex• 2 years ago

Undo should be standard for act on press and act on release flows.

eviks3• 2 years ago

There are actions without undo like "Send form data" (unless it's a fake send like in some emails). Though also can be rearchitected...

hresvelgr• 2 years ago

I am in mouse down camp. When it comes to dragging off a button to avoid triggering, I've done it many times, but it always feels wrong. It's like I'm taking advantage of faulty behaviour. Because of that instinct I'm inclined to believe that there's a better alternative available, like being able to undo easily.

On the note of draggable elements: don't overload affordances on UI elements. If it's draggable, don't make it clickable too. It creates a conceptually simpler experience. As for drag scrolling on mobile, that requires intervention to avoid erroneous triggering. Though when we're talking about "clicking" we're talking about Desktop + Mouse.

bmitc4• 2 years ago

If it's draggable, don't make it clickable too.

But that simply just doesn't work. For example, hyperlinks are both clickable and draggable. It doesn't make sense to remove one or the other because of some strange reason. There's a reason why actions are taken upon release and not upon down. There's literally no reason to take action on down.

parasti• 2 years ago

Very contextual. I've been appreciative of act-on-release in UIs where I can click a button with the mouse and then drag away from the button before release to change my mind. And that UI behavior has been around forever, way before touch UIs.

Toutouxc2• 2 years ago

I had an e-scooter where a double click on the mode-select button would turn on the light and respond with a little beep. A single click would just switch the mode with no beep. To this day believe that the beep always came before the second click. I tried to trick it by clicking it once and only thinking about the second click — and the beep never came. But once I committed to the second click, I swear it would beep a fraction of a second earlier than that happened. Whatever it was that the button was connected to, it was insanely fast, just immediate. My brain had been so hardwired to expect every human-machine interface to have a delay, that the button responding immediately to the second click felt unnatural, broken, magical, and honestly kind of creepy.

teaspoon• 2 years ago

But once I committed to the second click, I swear it would beep a fraction of a second earlier than that happened.

There’s a (very) short story about a device exactly like this: https://www.nature.com/articles/436150a

anon456354• 2 years ago

Negative time delay?

"What's expected of us" by Ted Chiang:

https://www.nature.com/articles/436150a

eru8• 2 years ago

Thanks, that was a great read.

Rygian• 2 years ago

They might have doped their silicon with https://en.m.wikipedia.org/wiki/Thiotimoline

tialaramex3• 2 years ago

Although this particular trick isn't possible, it is desirable and sometimes you can mimic such features which seem impossible.

I remember at around the turn of the century a friend showed me a neat trick many Sony MD recorders could do, which I think has since been incorporated into many (but IMO never enough) digital recorders: Time machine.

The compression needed for an MD recorder means a PCM buffer is needed, if we run the buffer all the time (after all it's just electronics) some engineer realised that this means you could choose to record audio that happened (and thus was in the buffer) before you actually decided to record it.

When one of the band members drops an instrument & it makes the coolest noise you've ever heard, you have long enough to think "Fuck that sounded so cool" and reach across and hit record and still capture the sound.

eru8• 2 years ago

I think phone cameras might be doing that these days, too?

Not constantly, but as long as the camera app is open?

hi-v-rocknroll3• 2 years ago

It was probably positive edge-level triggered (and debounced) without considering the second release event. It's a common failure of digital interfacing state machine design.

eru8• 2 years ago

To this day believe that the beep always came before the second click. I tried to trick it by clicking it once and only thinking about the second click — and the beep never came.

Does your explanation account for this behaviour?

amanzi• 2 years ago

The "Leave" button in MS Teams only works on release. Towards the end of a video call, as the meeting is wrapping up, I press and hold the Leave button, waiting for the optimum moment to release...

numpad02• 2 years ago

Isn't it carry over from anti-chattering/de-bouncing feature?

Most micro-processors has useful edge- and level-detect interrupt features that allows instant unconditional jump to interrupt handling subroutine(think callback functions) often used for physical buttons handling.

And one of common knowledge associated with that is, physical buttons tend to go through a transitional random state while being pressed, generating rapid succession of false on-off signals. This could trigger the interrupt detection feature, and while there will be little chances of memory leaks and no GC mess from this at all thanks to interrupt systems being static objects, it could still put system in a weird state and/or massively slow it down.

The most typical solution to button chattering problem is as follows:

  1. have the button input pin triggered for rising edge(button not pressed to pressed).   
  2. upon detection, immediately disable interrupt upon trigger, optionally send button down event to OS.  
  3. wait a millisecond, or for whatever duration the button takes to settle.   
  4. while at it, re-trigger the interrupt now for falling edge to detect button release.   
  5. on falling edge, pass the button up and button click events to the OS, or call the onClick() callback, and configure everything back to 1.  
  (0. call the hardware guy cubicle for further discussions)

... which results in classic MacOS style behavior of button press greying the button without action, and that is cute.

But the point is, it's less of a UX feature, more of hardware quirk suppression. Certainly a VR keyboard button virtually pressed by 3D spatial location of individual fingers don't require such pieces of anti-chattering code.

[expletive], I'm bad at drawing conclusions. Maybe I could say, by Chesterton's Fence principle, here the theory of Act on Release implementation is explained, and removal of fence can now be freely discussed.

bryanlarsen• 2 years ago

Debounce makes act on release a lot harder than act on press. If you want act on release with a bouncy switch you have to actually act on N number of milliseconds of switch open to ensure that it's an actual release and not a bounce.

Act on press is simply just rising edge and then suppress for N milliseconds.

xnx• 2 years ago

Not to mention this is the way that physical buttons work in the real world. People would be immensely annoyed if suddenly doorbells, elevators, light switches, etc. didn't operate until release.

dwhl• 2 years ago

I think the difference is that you can touch physical buttons without activating them, making it a two step process analogous to activation on release on touch screens.

Jtsummers2• 2 years ago

Physical buttons use edge and level triggering, and depending on the system either leading or trailing edge triggering. They don't universally use leading edge triggering.

bmitc4• 2 years ago

The aren't the same thing though.

yencabulator2• 2 years ago

You can press an elevator button part of the way, without triggering it.

abdullahkhalids• 2 years ago

I have actually encountered doorbells that ring on release. A bit surprising but hardly annoying.

jordansmithnz• 2 years ago

Some cases yes, but in plenty of cases, this wouldn’t be great.

- Browsing HN, and your scroll gesture happens to start where a link is? Before you know it, you’ve navigated away.

- Long pressing to delete an app, and the app opens in the meantime? Awkward UX.

In the majority of cases, press gestures are competing with other gestures like scrolling. Waiting until you’ve released is often the first moment that it’s 100% clear which gesture you intended. If both gestures get invoked, it will probably lead to much worse problems.

I’m sure there are cases where act on press makes sense, but I don’t think it’s as dramatic as the tweet makes out.

abtinf5• 2 years ago

https://twitter.com/ID_AA_Carmack/status/1787859646104928405

For example, it should be easier to cancel an app launch in VR that you miss-clicked — it is irritating that the meta button doesn’t work during the launch process.

Or just implement an uninstall apps screen in settings. The ratio of tapping to launch apps on purpose vs deleting an app is, what, infinity:1?

Bjartr• 2 years ago

Awkward UX

Yep, UX design is all about tradeoffs. So it's important to ask: What is more important to have UX polish? Uninstalling apps, something that happens rarely for most users? Or launching an app, which most users do dozens or hundreds of times every single day?

Adding a couple of taps to the uninstall workflow, whether it be a settings screen or a way to switch the app list into a select-to-manipulate mode, seems like a good enough UX for less common tasks if the percieved responsiveness of the device is improved.

jayd162• 2 years ago

He clearly points out that scrolling is a good enough reason t o break the rule.

- Long pressing to delete an app, and the app opens in the meantime? Awkward UX.

I don't think he's envisioning a world where long press and act-on-press are valid on the same object. You'd have to abandon long press and double clicks.

veidr• 2 years ago

Well, you don't have to abandon double clicks in probably the most common case, where click is a non-destructive action like "select" that can precede the double-click action (e.g. "open").

Long-press does indeed have to go, though.

AlphaWeaver• 2 years ago

In some safety critical software, it's important to do the opposite, to provide a means for a user to abort partway through the action of clicking (by dragging their mouse off the control with the button still held.)

abtinf5• 2 years ago

How about register the action but start a timer to allow cancellation?

tshaddox• 2 years ago

Wouldn’t that likely make most presses take longer, since the cancellation timer would surely be longer than the duration people keep the button pressed before releasing?

mattw1810• 2 years ago

Funnily enough I recently noticed that the X app on iOS started doing this for me… on ads. If I place my finger on an ad while scrolling down, without fault it opens the ad overlay sheet. I guess that’s one way to increase CPC revenue

egypturnash• 2 years ago

I am 52 and have been using computers for most of my life and there are still times when I realize I have clicked the wrong button, and slide my pointer/finger off of the button into a safe space before I release. Carmack sure does have a preference that would result in me swearing and reaching for undo, or swearing because whatever minimum viable webshit app I’m using doesn’t have an undo.

TacticalCoder• 2 years ago

... and slide my pointer/finger off of the button into a safe space before I release

Exactly the same. Now I do agree with Carmack on this but, like you, I've been "trained" that the action happens on release and so, unconsciously, over the decades, I've come to fix misclicks by not releasing inside the button but outside the button.

I don't use the mouse that much but this change would still be problematic for me.

At the very least if an UI implements that, then the UI should show that the button is released immediately (even if the mouse button ain't released), to make it clear the action registered.

divbzero• 2 years ago

This reminds me of fastclick.js [1], a library developed by FT to eliminate the 300ms time lag that used to exist between click and navigate on mobile browsers. The lag allowed for dblclick events but has been removed in recent years.

[1] https://github.com/ftlabs/fastclick

yencabulator2• 2 years ago

SvelteKit does this by default for in-app links, but it's still just preload, not actual activation. Actual navigation happens on release.

charles_f• 2 years ago

Extremely anecdotal - but for whatever reason I read the first two paragraphs thinking JC was talking about marketing. I was both quite confused by the fact that you should have 2 events, one for the press, and one when you release. I thought that "the thing" was some allusion to a marketing concepts that I wasn't familiar with. I was also quite saddened that John Carmack would post about marketing. Turns out I just need to learn how to read.

jddj• 2 years ago

Select (for further action, think single click of a filename in a file explorer) should occur on mousedown, that's about the only thing.

While we're talking about how things could be better, though, long static hold on a draggable item on touch devices should natively cause dragstart.

bmitc4• 2 years ago

He better not quit his day job as a graphics programmer. Act on press is a terrible design the vast majority of time and almost always has unintended consequences and is incompatible with other interactions, such as disambiguating something that can be clicked but also dragged.

it reduces user errors

Act on press significantly increases user error because in most cases, it is not the norm, so when it shows up, users take actions they didn't mean to. I can't stand it when a button is act on press.

and it is good UI design to favor them when possible

Saving tens of milliseconds in a button press does not automatically correlate to good UI design. Saving time is the only justification he gave, which is what you'd expect out of a graphics engine programmer. And he just suggested before this line that it would be good to have mixed behaviors, which makes no sense.

Jtsummers2• 2 years ago

That study makes sense given that it's about virtual keyboards, and most users expect keyboards to be act on press (since physical keyboards are). The issue, for me, is that he's extrapolating from that study that all (or nearly all) systems should be act on press, which doesn't actually follow.

You'd need a study showing that subverting user expectations (act on release) by switching to act on press reduces error rates (or at least doesn't increase them). Take a web browser and make every click (even those intended to be a click and drag, like to a bookmark folder) act on press. See how much more often (or not) users use the back button for browser history, for instance.

armchairhacker• 2 years ago

This is problematic on touchscreens because:

- Sometimes the content can be scrolled, so it’s not clear when the user presses whether they intend to scroll or actually press the button. Similarly, sometimes the pressed item can also be dragged.

- Other times the buttons may be small and the user may have fat-fingered, so it’s important they can drag outside the button to cancel (or in some cases, like the keyboard, maybe select a different button).

- Some buttons have special “long press” or “hard press” actions, particularly on iOS. This is really good UI, and it only works if the button’s normal trigger occurs on release or the normal trigger segues into the long-press trigger.

- Even when none of the above apply, the user is still conditioned to expect the button will trigger on release. They aren’t going to deduce “this button isn’t in a scrollable area and is large enough and has no long-press action (or the normal action segues into the long-press action), so it will trigger instantly”.

- It almost never makes a difference to wait for the user to release. If the content loads fast enough, it will load before their brains’s reaction time (they are releasing the button before their brain can start processing new content). If you really care, to remove 0.1 seconds of latency, you can preload the content when the user taps the button, commit it on normal release, and revert it on cancel. Toggle and selector buttons have no immediate effect, so for them it never makes a difference.

On desktops it matters less whether buttons trigger on press or release, but IMO it still matters. “Long-click” isn’t common and scrolling is done differently, but there are still draggable elements, “fat-fingering”, and conventions. The thing that matters, for both desktop and mobile, is that the button or item has a “(being) pressed” state that looks different than the selected state. IMO if the button doesn’t have a pressed state, it feels more natural for it to trigger on press; but it feels more natural for the button to have a pressed state than not, and when it does have this state, it feels more natural for it to trigger on release.

UI elements that the user “taps and scrolls” (minus the text cursor) like sliders and color pickers are typically expected to react instantly to the user’s touch (and a slider or color picker in a scrollable view is bad UI, because it interferes with this). Although even these elements I’d prefer go into a “pressed” state, to indicate that if the user releases or scrolls within the control it will switch to the value at their finger, but if the user cancels (e.g. simultaneously presses somewhere else with another finger, or scrolls vertically outside of a slider) it will keep its original value.

The one place instant-trigger buttons are important is real-time game UI, where reaction time is important, hence the author’s observation. Although instant triggers don’t matter in out-of-game UI, there are reasons why they may carry over: said UI may be written in the same framework, with the same developers, or the studio may wants to make the entire game’s UI responsiveness consistent. Non-real-time games may also benefit from instant-trigger buttons, although I’m less sure of their importance in these games, it seems they are common. Perhaps a game like Shattered Pixel Dungeon would feel “delayed” if it didn’t have instant triggers, especially if you are playing it really fast, even though AFAIK time in that game is entirely determined by your sequence of inputs.

jayd162• 2 years ago

As much as I would also like to drop double clicks and long presses and only use fast and discoverable interactions I think that ship has sailed...

A less militant solution might be highlight-on-press. We can at least ensure the UI is as visibly responsive as possible even if actions need to wait for gestures to complete.

seabass2• 2 years ago

I recently had this debate with my friend, who built this fun test to see how much latency was actually added by waiting for mouseUp: https://click-duration-timer.vercel.app/

I felt pretty strongly that I would hate triggering events on mouseDown because of how often I "cancel" an action mid-click. But I decided to add this userscript to my browser and live with it for a week:

  let preventNextClick = false;
  const interactiveElements = ['a', 'button', 'input', 'select', 'textarea'];
  
  document.addEventListener('mousedown', (event) => {
    if (event.metaKey) return; // allow cmd+click to bail
    if (event.button !== 0) return; // handle left clicks only
    
    // ignore all but a handful of elements
    const tagName = event.target.tagName.toLowerCase();
    if (!interactiveElements.includes(tagName)) return;

    event.target.click();
  
    // set a flag to prevent firing two click events
    preventNextClick = true;
  });
  
  document.addEventListener('click', (event) => {
    if (preventNextClick) {
      event.stopImmediatePropagation();
      event.preventDefault();
      preventNextClick = false;
    }
  }, true); // use capture phase

This causes any of the interactive elements on a page to trigger their onClick action during the mouseDown phase rather than onMouseUp. It's probably not perfect, just a scrappy user script. But omg it is so much nicer to browse with this enabled. And I say that as a hater of the original idea with strong opinions.

So, if you want to have a slightly more informed opinion on the issue I suggest trying this or something like it out for a week! I can't go back to the way it was before. Everything is so snappy now.

I haven't (yet) found a case where I wished I had the mid-click cancelability I had before. I think that getting used to the idea of clicks being instant rewired my brain a bit to simply not rely on that behavior anymore.

wodenokoto2• 2 years ago

How does dragging work when mouse down is a click?

seabass2• 2 years ago

That's a great point. Dragging on any of the interactive elements currently fails. Building in the cmd+click option to bail out makes it possible, though.

darthoctopus• 2 years ago

thanks for the script!

mike_hock• 2 years ago

Act on release. This is a UI design hill I will die on.

Yeah, in FPS or other games where reaction time matters, or just games in general, you always want to act on press.

In all other apps, act on release.

alabasters• 2 years ago

This makes me feel like this guy was hard to work with. His attitude just seems a bit cocksure.

jasonlotito• 2 years ago

If you implement act on press, and it's "destructive" in any way, and you don't have a way to reverse it, you are wrong. Carmack is usually smart, but this is a hill he'd easily die on any day of the week.

hi-v-rocknroll3• 2 years ago

It depends. Fire guns and most controls? Yes. Self-destruct the ship? Hell no.

The whole point of having a release event is another UX usability principle: being able to undo a click or tap.

Having disabled players conducting real UAT to ensure UX is appropriate for a wide audience is also important.

sa46• 2 years ago

https://instant.page/ is a take on this idea for web. On mouse down or hover for an <a> element, start a prefetch.

This technique hides about 80 ms of latency when triggered on mousedown and up to a few hundred milliseconds for hover.

omgin• 2 years ago

I just found a firefox plugin which automatically redirects x.com links to nitter:

https://addons.mozilla.org/en-US/firefox/addon/nitter/

chrismorgan• 2 years ago

When it comes to actions (by which I mean commands) in conventional UI, all desktop platforms follow the well established convention: keyboard acts on press, mouse acts on release. This doesn’t mean that there aren’t controls that react on mouse down—focusing an input field, for example, is a mouse-down thing, and you can immediately start things like text selection thereby; and draggable things like scrollbars are also naturally exempt from this. But basically everything else, certainly things that are for taking actions, should act on release, if you’re activating them with a pointing device.

From time to time I encounter web systems that get this wrong, using keyup or keypress instead of keydown, or using mousedown instead of click¹. Most people won’t notice, I expect, but I suspect I pretty much always immediately notice and find them infuriating, because they break the universal convention—things that you’re used to being able to do, don’t work as you expect. Perhaps my favourite example of this was some system which would close some form when you released Escape—so when I had something else open above the browser at the OS level (or maybe it was even just a <select> dropdown! Actually that sounds right; I know I triggered this too often) and closed it by pressing Escape, the web page underneath then received the keyup, and so the Escape press closed two things in one go, which was never what I wanted.

If you can start executing an action on mousedown and only commit it functionally and visually once it turns into a click, go ahead. But otherwise, please don’t act on press, because it’s wrong.

The on-screen keyboard he mentions… well, I’m actually a bit puzzled by that, because it should completely obviously map press to keyboard press, and release to keyboard release, and anything else would be wrong, so how was there ever an argument, and in fact how else could you implement it? I genuinely don’t see any alternative, if you’re working on an OS that has the concept of keyboards already. Ultimately, I don’t think it supports his point at all, because he was implementing a keyboard.

—⁂—

¹ Note that even monitoring mousedown + mouseup may sometimes be wrong, due to nuances that can cancel the click mid-press; things being draggable is the obvious example, but I think some platforms let you hit Escape on a keyboard, or maybe have other multi-pointer quirks.

eviks3• 2 years ago

This is a UI design hill I will die on... it makes the interaction feel substantially more responsive, and it reduces user errors by not allowing the focus to slide out of the hot box between press and release

Sliding out is also exactly how you cancel events we when you realize you've made a mistake by clicking on autopilot.

Though hard to say definitively which one is better without more explicit comparison of these two styles of interactions

nektro• 2 years ago

and it reduces user errors by not allowing the focus to slide out of the hot box between press and release.

well thats one way to demonstrate a misunderstanding of many UI

wodenokoto2• 2 years ago

Then please die on that hill.

Cancelling an event after down press is really good outside of games.

In games holding a button down for a little or a lot longer is a good stand-in for “pushing hard” which you want the game to react to.

darylteo• 2 years ago

I wanted to see how consistent this may be in practice on mobile iOS, focusing only on elements that are "tap" only.

- most elements are ON RELEASE

- except the phone number entry or passcode entry, these are ON PRESS

   - but the "backspace" button is ON RELEASE

I'm guessing because there are so many other interactive options on iOS (touch hold, hold drag, 3d press, swipe) this proposed paradigm is less likely to have much impact.

eru8• 2 years ago

I do agree with his example that a (virtual) keyboard should act on press.

Even if I disagree with the concept in general, unless you have very simple and pervasive undo, perhaps.

dusted2• 2 years ago

I disagree with Carmack on this, I'm on the other hill. The press-on-release affords me the chance to bail at the last minute. It's probably because my brain is defective, but then consider it a handicap aid! But something about the way I work, makes it that my last cognition will often happen as I'm holding down the button, and it's not uncommon for me to realize that "oh shit, this is the delete button, I meant to save!" and! With the do-on-release, I can keep holding down the mouse button and carefully move the cursor OUTSIDE the button, so that the action is not executed.

Lot's of places, I want faster response (the controls in computer games, yes, of course!) but NOT in interface elements, there I want the response on release, so I have the extra opportunity to realize my fuckup and amend the situation.

solarkraft• 2 years ago

Thanks, I hate it.

it reduces user errors by not allowing the focus to slide out of the hot box between press and release

No, it increases user errors by not allowing the focus to slide out of the hot box between press and release.

tiffanyh• 2 years ago

This is exactly how https://instant.page/ makes webpages load so fast.

It cheats your brain by loading the new page once link is pressed (or even hover). Not on release.

Act on Press

Related Stories