Act on release has saved me from making some very bad decisions..

@SandraWantsCoke

Ай бұрын

Like an unplanned child?

@lukaswalker2342

Ай бұрын

same. John carmack is a game dev and for games i would say he is right UIs feel faster with act in press but on websites i prefer act on release

@danhorus

Ай бұрын

You can also use right click to cancel a left click that's being held

@SandraWantsCoke

29 күн бұрын

@@danhorus oh you haxxor!

@pik910

28 күн бұрын

@@lukaswalker2342 Even in games missclicks can painful. For things like triggering abilities act on press sounds good, but for skill trees or dialog choices it does not. And based on personal experience act on release really does prevent mistakes and the delay has never really been an annoyance or felt slow.

Maybe we should introduce the "speculative execution" on press. A click starts executing the action, but depressing it outside the button cancels it and reverts back everything done so far. Complexity ensues…

@burger-se1er

Ай бұрын

The point of 'on-click' is to *feel* more responsive. Executing 0.1 seconds sooner without updating the display won't help, and leaving the button floating there to be unpressed will look weird sometimes.

@D-V-O-R-A-K

Ай бұрын

​@@burger-se1er Of course it will feel more responsive, because on average, the delay between press and result will be shorter

@burger-se1er

Ай бұрын

@@D-V-O-R-A-K Carmack is talking about the delay between press and displaying the "rendering video..." screen, not the delay between press and the rendering being complete. The rendering process takes long enough that starting 0.1 seconds sooner won't be perceptible. You could even change to the "Rendering video..." screen on press but wait for release to actually start the rendering process and it would feel identical to everything happening on press.

@gwentarinokripperinolkjdsf683

Ай бұрын

@@burger-se1er yes, this is his idea of using "speculative" execution, for instance you can start opening the new web page, but if they would release outside the button bounds, it would instantly go back. this would probably be awful to be honest but it's a funny idea

On highly-interactive, real-time applications such as games, where high responsiveness is an expected feature, I guess I could agree with Carmack, especially if the human-machine interaction is done with direct touching. But as for regular UIs commanded via a pointing device I hope the act-on-release paradigm will remain a thing.

@Lars-ce4rd

Ай бұрын

Totally agree, I thought the exact same thing. I thought for in-game scenarios it makes sense, but for web apps, desktop apps and even game menu systems, it doesn't make sense IMO. I definitely don't buy the argument about accidentally moving the cursor in case of small buttons. On any user friendly UI, buttons should not be so small that that can happen and it's more likely that a misclick is due to a brain fart than such an accident. In that case it's better for the user to have the option to maybe not release the mouse click. This has saved me a few times.

@Asdayasman

Ай бұрын

It's almost as if Carmack is an excellent GAME programmer, and an expert in his area. ... And not others.

@whannabi

Ай бұрын

​@@Asdayasman who the heck is he

@Kapendev

Ай бұрын

​@@Lars-ce4rd It is not difficult to move the cursor accidentally before the release. Even if the button is large, your mouse may be at the button boundaries. I'd say it's a matter of preference.

@turolretar

Ай бұрын

It should be an accessibility option IMO

Ok, so in the end it is not "use one or the other" but "keep both in mind and apply the best one for the situation".

@forestrf

Ай бұрын

After reading your message I thought "yep, this is actually the solution. You saved me probably 10 minutes of my life" and then I saw how long the video is. Thank you.

@pkramer962

Ай бұрын

@@forestrf you're welcome. however i can still recommend watching the video. he explores the idea and has some interesting points in which case one is better than the other.

@10Rmorais

Ай бұрын

As most things in software engineering

@doltBmB

18 күн бұрын

Wrong, the inconsistency will lead to tears.

@wojteksowinski248

17 күн бұрын

​@doltBmB Depends on how inconsistent you are. If you just randomly make half of your buttons act on press and the other half act on release then yeah, it might feel inconsistent. But if you make one consistent choice per application or one choice per type of widget then I don't think that's a problem. Most users won't notice when a ui element acts on press and have never even heard the words "act on press". To them, some ui interactions "just feel faster / more responsive" but they wouldn't be able to tell you why that is

The slipping effect is actually really important for people unfamiliar with mice and touchscreens. It takes people a while to learn to click without sliding the mouse sometimes

@insentia8424

20 күн бұрын

Or for games/applications where you perform many quick movements and clicks between them´. Or during the movement. Or there is an incentive to do either of those two. If you make it on release on those rather than on press, than you are inconveniencing the user, or even wasting their time.

@thelastdankbender4353

12 күн бұрын

So true. Took my mum years to consistenly release the mouse button. She always saw pressing and releasing as two seperate actions that needed individual attentention because she was scarred of doing something wrong. It's crazy to think how hard most boomers used to struggle with skills that are seen as essential nowadays.

for any clickable item rng between 0 and 1, 0 = on press, 1 = on release

@howdoiexitvim-sg2xl

Ай бұрын

this is fucking evil XD

@azai.mp4

Ай бұрын

0.5 = the moment you press, an AI predicts when you'll release, and the act happens at the exact middle between when you press and when you (are predicted to) release.

@thephoenixsystem6765

24 күн бұрын

@@azai.mp4 Most appropriate use of deep learning

Can't remember how many times has act on release saved me a click I didn't want or did accidentally, or the "anger" of certain apps/uis with act on click I feel more in-control with act on release, as I have to decide, and commit to the click by releasing it

@ardiannm

Ай бұрын

Then it's a mindset issue; you act before thinking where you want to navigate. You wouldn't do that if you knew there was no option to allow for errors. You would quickly adjust and wouldn't but the cursor inside the button without being sure you want to go in. I mean, if you keep entering the rooms in your house before thinking if it is someone else's private room then just because you can always get out and close the door, that doesn't make it any better. There is clearly something wrong with you, for entering rooms without much thought and with a mind elsewhere. Also I would hate to live in a house where I would have to press the doorhandle and see the door open only after I release it. Try buying those kind of doors (if they exist) and see how you feel about it.

@marwan7614

Ай бұрын

​@@ardiannm hands down the worst analogy I've ever witnessed.

@whannabi

Ай бұрын

That's something you usually discover yourself and end up expecting from every interface with a mouse

@EnDeRBeaT

Ай бұрын

​@@ardiannm​this is a horrible analogy. "Mindlessly wondering around rooms because you can always get out" is an exact mentality of people who love act on press and are relying on a good undo mechanism. Moreover, your doors are already act on release, well, in a way that opening a door is a 2 step process for you too. You are pressing the doorknob, and then you are pulling. You can always reconsider pulling, that's pretty much not what act on press enables you to do. However if your doors would have busted wide open on any slight contact with a knob, boy, that would have sucked!

@ardiannm

Ай бұрын

@@EnDeRBeaT "Moreover, your door are already act on realease", no they are not. The rest you said renders meaningless considering you just made that statement.

How often does accidentally cancelling a click because of act on release happen? With a mouse, very rarely. On a touchscreen, occasionally. With VR motion controllers, all the fucking time.

@yehoslavrudenco4549

Ай бұрын

On a touchpad, however, the act on click makes it easier to err when just moving the cursor around. How does a button even know if the tap was to activate the button or to move tho cursor away?

@necuz

Ай бұрын

@@yehoslavrudenco4549 I don't see how it would make a difference. If you're unintentionally clicking, you won't have the presence of mind to cancel it either.

@miroaja1951

Ай бұрын

Idk if it's some weird attention thing, but sometimes I'm not exactly super intentional when I'm thinking through something. I like to click on things when I'm thinking of a process on the fly (like figuring out an animation in blender ect.), and sometimes a thought finishes as I'm pressing on a button. Having that surface to equate my thought process with the actions of doing something without actually committing to them is a really nice aspect of act-on-release. Especially in complex UIs act-on-release makes the UI feel more intentional and deliberate, and more a part of the problem solving process rather than just a tool to execute it.

@homailot2378

Ай бұрын

I'd say it's just as likely to accidentally click on something you didn't want to on VR.

@Sauvva_

29 күн бұрын

@@necuz you dont need presence of mind to cancel, the click just doesnt happen becausse you are holding to move the cursor, you moving the cursor or not is what defines a click

Fun fact: "Act-on-both" (or perhaps rather "act-on-any") is quite common in 1-on-1 fighting games. Suppose your character is performing an action. This action locks it into a state for a certain duration. While it is locked, you press a button for another action. Things can really only go two principal ways: either the press is ignored or it is buffered for use after the lock. There's a third way that combines the two, where the press is buffered within a timing window, but ignored outside of it (it is common to allow "cancellation" or "interruption" where a new action can be executed before the old one has finished, within limits). There's nothing unusual about this so far. Then you release the button. Why should there also be an action there? This can help in two major ways and possibly some others I haven't thought of yet. The first is, that in case your press was ignored, the release is a second chance to effect the action. The other and less obvious use is to chain actions. You can issue one action with the press and then already input a follow-up combination action (a.k.a. "combo") using the release. It is effectively a shortcut and makes the game feel more responsive (I guess more "technical") to play. If I remember correctly, the combo mechanic was originally introduced due to a programming error, but then kept in the game and later refined into what we know today. So, all thanks to happy little accidents and the people who notice them and recognise their potential.

The whole lost focus thing is huge. Watching boomers try to click a menial, unimportant button with their unstable hands is really frustrating because they can (understandably) never seem to release on the hot box. Act on release probably wastes a few minutes of my professors' days judging by how often this error occurs during their lectures. Important buttons, however, should definitely retain this feature

When somebody says "I will die on this hill" I say "by all means, you can use my sword!"

I loved the remark about recreational programming

I think the example about the keyboard app might not be very valid as the app changed how keyboards fundamentally work. Physical keyboards are act on press, phone keyboards, act on release because the key might have a second character it can produce. I think the perceived speed from act on press might be your brain playing games on you, because you now try to measure and see the difference. Whereas, naturally, you just press or click and go to the next thing. You are not even thinking of the release.

@Cmanorange

Ай бұрын

act on press makes it responsive, act on release makes it precise. i'd rather have the ability to "unclick" a button than remove milliseconds i was probably spending blinking

@marioprawirosudiro7301

27 күн бұрын

Keyboards are NOT "act on press", physical or otherwise. Every single keyboard buttons in existence sends exactly one electrical signal when it's pressed, but it is up to the application how to interpret that signal. Most GUI frameworks (Gtk, Qt, game engines like Unity, heck - even WinForms) would send one event when a key is pressed, and another when it is released. It is entirely up to the developer how they want to handle it.

@cube2fox

10 күн бұрын

Physical keyboards are indeed "act on press" when it comes to their main application -- writing text. I have never seen a text editor which does act on release for physical keyboards.

I like "act on click", where a click is both press and release within a small number of milliseconds and a small number of pixels of motion.

@TV4ELP

Ай бұрын

Honestly, the motion part is a problem for everyone with low mouse DPI. It's totally possible to click without any pixel being moved. On touch, sure, otherwise? Press & release

@miroaja1951

Ай бұрын

Bumping cuz fuzzy logic clicks on mobile devices are amazing

@zwenkwiel816

Ай бұрын

​@@TV4ELPthink he means maximum pixels moved. So 0 is fine too but if you make a large motion while clicking it probably shouldn't register.

"Make mistakes easy to undo", or like, just allow me to cancel them immediately, instead of going through the easy undo process

@CHEpachilo

Ай бұрын

Well I have some experience with software which has some form of "Rendering" in it. And for those operations I highly enjoy "start on release" because it is extremely high intensity action and I a lot of times found myself realizing some kind of mistake pressing the button down and thanking developers for possibility not to start -> cancel -> fix -> repeat, but just avoiding start.

@KryptLynx

27 күн бұрын

Funnily enough, "press on release" is a such example of "make mistakes easy to undo".

Time for some double-blind tests. The answer is always, "it depends."

@synthmaker

28 күн бұрын

I think that depends.

Act on release made its way from early OS's to the touch screens of today for good reasons.

I can't tell you how often I click a button only to realise before release that that's not what I wanted to click. Tech without cancellable clicks would be a hellscape for me.

0:31:00 - 1:36:00 i spontaneously walked out of my apartment and went for a walk (after a very long time), so sweet that video was still playing when I came back. Apparently you have a very therapeutic channel.

Keep the good work

It really depends on the context, in the engine I am developing for my game, I support both in the UI and use them in the game in different situations. If a decision has irreversible consequences, I use act on release (e.g. casting a spell). If it does not have severe consequences, act on press feels much more responsive (e.g. click on enemy to see stats, switch items in inventory, etc...).

Most things are on release not because of "user can rethink their decision", but rather because the button/thing supports dragging/being moved. You can't have on press actions on those buttons otherwise it's not possible to drag them. Other places try to behave similarly (notable exception: browser tabs).

@htspencer9084

12 күн бұрын

It is possible to support drag with act on press, to be fair.

Another reason for act on release is that if you keep pressing a button, that may sometimes open a menu whereas just clicking the button performs its default action. That's another common pattern, Carmack called it "long press menu" and it's a pattern I like a lot. It's also a real-world pattern, as I have hardware (physical buttons) that trigger different behavior if you keep pressing them for a few seconds (e.g. almost any old school digital watch has such a function somewhere) Last but not least, sometimes I don't click on a link on a webpage to open that link but to copy the link text, which is not possible if a click immediately activates the link.

I know you enjoy experimenting, and that's fine, but I gotta say, the moment you started thinking of ways to workaround the problems that act-on-press caused with your render button, it was instantly obvious to me that you were ditching the simplest solution in favor of needless work and wasted time, all for a net gain of... nothing. No benefit. Because act on release is really a non-issue, which also happens to mitigate those problems for free.

@judahmatende3769

Ай бұрын

you obviously haven't watched tsoding long enough

@skaruts

Ай бұрын

@@judahmatende3769 I obviously have. I said I know he enjoys experimenting.

@gerooq

28 күн бұрын

@@judahmatende3769literally

@htspencer9084

12 күн бұрын

We're not here for the engineering and we're here for the over-engineering 😂

@skaruts

12 күн бұрын

​@@judahmatende3769 if only youtube would let me respond to comments, I would tell you your comment is completely missing the point... (and outright wrong).

The problem with killing ffmpeg through PID is that you must be sure that it is STILL a ffmpeg process. I think robust way to do is to check first that pipe is not closed by ffmpeg and then kill PID. Or just close pipe yourself and forget about it. Also Linux sends a SIGCHLD to the parrent process if one of its child processes died. You can catch it and waitpid(-1, NULL, WNOHANG) in a loop until you get all the exit codes. That's what dwm (the window manager) does.

I'm too used to the way things are. 30 years of accumulating hemorrhoids behind a screen made it such that I barely even notice minute details like these. That being said, I think there's a place for both approaches where functionality (i.e. UX) requires it. This is not one-to-one for what Carmack's talking about, but, for example, as much as I hate Photoshop, back in the day it stole some old-school paradigms for its UI that I appreciate very much and rarely see in younger programs. I'm mainly talking about the fact that it's "partially modal", where you can press and release and go into "brush mode" permanently, or press and hold if you need it for immediate touchup - then, when you release it PS goes to your previously selected tool. This is GOLD! Dead CG software called XSI uses it all over the place and to this day I consider it THE BEST when it comes to polygon modeling precisely because of that small feature. Everything feels like it's right at your fingertips, never too far behind multiple button presses. Especially When you DO need to consecutively apply some rarely used modifier (that therefore is not committed to muscle memory) and jump between it and commonly used tools like move, rotate, scale, etc. ...my ultimate point is that as with all things, there is no universal blank slate approach. And the fact that someone besides me is even thinking about it makes me happy. :D

Missed a chance to title the VOD: "Making my UI CRISPER"

I am a gamer, I like crispy. I don't want to go into the recycle bin when my finger has decided that the file must go, but my arm says no. The user should be aware, before interacting with the element, which type of button it is. Currently, there is no precedent in the design language differentiating between the two. Act on press feels more fragile and unsafe, just like how I feel in a file manager with single click to open instead of double click. Buttons that don't have any consequences should be act on press. Loss of time trying to undo the press is also annoying.

The only instance of act on press I know is the Fortnite "Invite friend to lobby" button. It's crazy how instant it feels, it feels like it activates before I even click it

I remember this causing some controversy in samsung phones shutter lag, where it only takes picture once you release the shutter button while apple goes burst mode with act on press. I wonder if there can be specific applications for this. Interestingly all our hardware buttons are act on press buttons unless they are spring loaded or magnetic flip type buttons that can be more akin to act on release only after a tipping point. Both seem to have its uses and using common sense we can conclude that its better to use act on press for activation and registration, and act on release to invoke a state change.

Obviously the answer depends on context... so in Carmack's world of games, I likely agree. However in the general case, I'm an act-on-release guy. Especially for any form that commits, I want to be able to have one last "oops" opportunity to cancel the input. Doubly so as I age, and my mouse precision isn't as good as it used to be

NEW DAILY! LETS GOOOO!

I think it’s right for physical buttons, but not for a mouse click.

In Java, which is my main programming language, it's just a binding difference. whether you supply the function to onpress or onrelease

Recently I have been working on a VNC input layer on the web and I can tell you that act on press would just not be possible in a lot of situations. Touchstart and pointerdown events for example fire *at the same time*, you simply have no idea what the intention of the user is at this point, are they doing a gesture? a click? you have to wait for other events to fire to be able to get an idea of what the user is trying to do. Pointer events happen on both touch screen devices and non touch screen devices, and some devices have both capabilities (touch and precise pointer), act on release is the only realistic way to write a UI library that works the same cross platform.

@PetWanties

Ай бұрын

Games are probably the exception here though, especially if you need real time input and you *know* what kind of input you will be receiving (like LMB to fire a gun etc).

I have learned to do the following: before sending an email, review it. After reviewing it, click and hold “send” button and review it for one more second, then release and send. If the app behaves otherwise, I will feel lost.

For this application, i would recommend act on press except for that one button, because it's really slow to reverse

how do you know the reason for the universal act on release? Is there some resource you can reference?

@theodorealenas3171

Ай бұрын

He brought it up iirc. Why do people use as arguments all the things Carmack addressed, it's insulting, like they didn't even listen

Mouse clicks are normally act-on-release because you don't know at press time if the action is a click or a drag.

I would say it's a lot more about what mindset an user is likely to be in when they click, whether its reactive or complentative. For example, with a video ui play/pause button. A pause is often reactive, you notice a thing and reacts quickly, so you should pause on press, or you might pause to late. When you want to play, you contemplate on the action and act on it afterwards, so play on release, ad you might click accidentally before having actually decided and want to cancel.

For games, act on press. For anything permanent (send, commit, exit)... at Least act on release or ask to confirm.

this is literally only relevant to VR. I've never in my life missed a mouse click/screen tap because I was moving the mouse too fast to finish clicking it within the button.

I like the sliding feature

There are two things that always get me with this, whether talking web or native. First, UIs with a lot of separate articles (think list of tweets) have a *lot* of interaction points. If the stance is "if you click on the tweet body, you can flick to scroll, but if you touch a username or an avatar or a like or a retweet, etc, it happens instantly" leads to a very tricky landmine to navigate with your thumb (or VR pointer, or anything else). The second problem is views. The problem with act on touch is that if a transition happens instantly, your thumb/pressed mouse/VR pointer/whatever is now *pressed* and on top of new UI on some new view. If you put your thumb down on a "next" button and all of a sudden it's still pressed down and on top of a "purchase" button, because within 8ms, the entire view had been replaced with the next page, that feels like a landmine. One single tremor while removing the thumb will lead to a credit card charge. And then what does the cancel button do? Submit a refund request? There are times where immediate action can be useful, definitely, but I prefer immediate responsiveness, not immediate action. A lot of our current UI doesn't have the same level of responsiveness as older UIs. When you touched buttons, there was a very visible press visual and a release visual. UIs always felt like they were being touched; often including sound effects. And those effects were "immediate". I don't buy that the action has to happen as your thumb lands on a hitbox. But I do believe that UI should tell the user that it is responding, and not just be a flat image until release.

@monad_tcp

Ай бұрын

See, the problem is that web developers are lazy. You are correct about the thumb press, but when we're doing a mouse click its a different event. Why are we even discussing doing the same action for two different events ? A mouse is a mouse. A thumb is a thumb. And a VR pointer is a VR pointer. 3 different events, that need 3 different actions, but the lazy web developers want to have a single action do everything, bah "There are times where immediate action can be useful, definitely, but I prefer immediate responsiveness, not immediate action." What the f do "responsiveness" even mean. You want immediate action always (or at least a visual/audible immediate response as the action happens immediately but on the background), even when are using your thumb in a smartphone, the difference is that the UI must stop responding to thumb events while you have the thumb down, otherwise the page change behind your thumb before you removed the press, and then another action happens. That's not a very hard and difficult logic to implement. The page should do immediate action, but the browser should wait, why's that hard ? Maybe the person writing his own browser is onto something.

@SeanJMay

Ай бұрын

@@monad_tcp @monad_tcp well, the reason we are discussing the same action for different input is because people who use accessibility devices and people who use keyboards and people who use typical nice and the people who use styli and the people who use a touchscreen all deserve to buy groceries and do banking. And that should be possible without writing 8 different versions of a site, and then compiling each of those 8 different versions across several OSes and screen formats. I'm not going to run defense for giant corporate conglomerates, or for too-big-to-fail consultancies and their hiring practices... but regardless of those things, it's all a harder challenge than just "git good and make 14 versions of the same thing at the same time, and synchronize bugfixes and feature launches". “why is it hard for the immediate action not to happen". Ok open KZread on your phone. Scroll down the list of comments. The "immediate action" is "reply". Do you intend to immediately reply to every single comment as you scroll? What if you are really, really careful not to hit the text... well, there are avatars and names... the immediate action is to load the details for that user. Ok, well, what if you are really, really, really careful and really good at flicking, and you get to a mostly blank spot, where the immediate actions are to like, dislike, etc? Which "immediate action" are you talking about? How about scrolling the list of videos, while listening to a video? Is your intent to watch it immediately, or dismiss it, or save it to a playlist or queue it, or share it, or were you hoping to scroll by it? Because the "immediate action" is whatever you managed to fat-finger as you were flicking through, and many of them will pause the thing you are actually trying to listen to right now. Scroll is impossible in that world. Pinch to zoom is impossible in that world. Picking something up to drag it is impossible in that world. To make those things possible there will have to be entirely new behaviors invented. And maybe "hold down the Alt / Option key" is it... but then you are back to needing a keyboard and two hands. Or you need to dedicate space on every touchscreen for the "virtual Alt" button. Or you need to somehow make that virtual button sticky for the people who navigate by looking at the screen and blinking, so they can do their banking and buy groceries. The problem isn't the code. The problem is almost never the code.

It's really a thing that needs to be decided on a case-by-case basis; for things where accidental triggers have serious consequences it's important to ensure it only happens when you're sure the user really meant it; meanwhile for things that are less impactful when pressed on accident responsiveness could have higher priority. For phone keyboards and such, since the consequence in most apps is easily reversible by just backspacing or something of the sort , that could be automated; triggering on press with the additional logic to handle correcting on long-press and swipe, definitely makes more sense.

"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 areas, long press menus, and drag-and-drop" Gosh, it's almost like different domains have different design pressures...

I appreciate Carmak, but we should go further: act on both press and release. Just imagine a thing: once pressing mouse to click buttonA you don't need to release it to click buttonB afterward, you can use the power of release which is still held by your finger!

I can see this working in the use cases Carmack works on, like Games and VR, but we'll need a complete redesign of our daily UIs for act on push to work well :/

It would be interesting if the author wrote demos of his mini games using ECS pattern, that would be a show.

Omfg thumbs up, favourites, comment, all the things for this right here 1:13:22 Lmfao you made my week, that's awesome 😂❤

Personally, when buttons act on press, I don't feel like they're _"responding to my wishes",_ I feel like they're acting before I confirmed my wishes. UIs that do that tend to make me afraid of clicking anything. I think John's arguments are a bit misguided. Sure, you can and should use on press in many cases, like switches, sliders, etc, but NEVER on regular buttons, and it kinda seems like he's not seeing this. Normal UI buttons should always be cancelable. And you do need to be able to slide out of the button in order to be cancelable. His point wasn't a good point there. You don't need to act on press to _"make the interaction feel more responsive",_ you just need the button to provide visual feedback to your click, as any decent UI does. Obviously, for a virtual keyboard, act on release is the worst thing you can do. But those aren't regular UI buttons. They're special buttons that mimic the behavior of keyboard keys, which act on press because otherwise the keyboard would be a pain to use. I think using a VK to backup his argument was a mistake, because it's not at all equivalent to a regular UI.

“Do on press” makes sense in the virtual keyboard context. It does not for web pages.

Not every application is Doom.

Pog!

Here's my two cents: depends on use case. Some things are better to have on release. Something you can (sometimes) do for on release things is have visual feedback while the button is down, in order to make it feel a bit more responsive, but the full action happens on release.

seems to me that we should be actually making the decision when we make a button whether we want that SPECIFIC button to be on press or on release

I'm an act on release person, but act on press is literally how most light switches, door bells, etc. work.

Act on release should only happen if act-on-press is actually a different function entirely. The Dark Souls sprint / roll button.

Tsoding -frontend developer

@cyberking1128

Ай бұрын

This is the real comment; bless the internet

The weird thing about act on release being a safety measure is most of the systems I use have a confirm step after the click for anything even half risky like deleting entries. Act on release and this feels so unnecessary. The funny thing about those 'are you sure' boxes is we naturally train ourselves to quick click through them negating their sole purpose.

dark souls has this button where if your duration of holding circle button on key up is less than few miliseconds, you roll. if you hold it longer, you run. it is kind of "act on release" and somehow intuitionally helps me time my rolls right

Would love to see some pico 8 content from you 😉

Act on release doesn't work with touchscreens and buttonless trackpads very well. It is better for things involving timing, as releasing a button is more reliably consistent than pressing it.

53:40 Andreas mentioned! Hail, Serenity!

I'd prefer act on press in games for sure and I've been more often annoyed at act on release than act on press

I'm getting strong "it obviously depends" vibes from this one

I get finger twitches so being able to cancel my click by moving off of what I pressed is very helpful Edit: It does depend on the type of application what I prefer though in video games I'd rather accidentally press something and have it be responsive, but on a website I don't want to accidentally click links etc.

Moving the punishing button further away is a good idea, but why didn't you consider a confirm of some sort - like a full popup with 'are you sure?'; or less in your face like - first click replaces the save icon with a red question mark and a second click does the thing; or even unnoticeable like - only the punishing actions are activated on release so you still get the chance to cancel if you get yourself in that situation, but the rest of the application feels better because of the act on press.

Costly operation could be confirmed, it add friction to the interaction so there is decision to weight. Which could also be mitigated by designing the ui where costly interaction are clustered in a different space than other interaction. But for synchronized media (music, video), I think it is better to interact on press because of how the media react would make it look more responsive. Otherwise actual cancellation could/should be done asynchronously, the idea would be to keep the interface responsive by deferring/delegating costly actions in the background, users don't necessarily need to wait until the cancellation is complete as long as they know that the action will be eventually cancelled. As pointed out, touch interface make act on release interaction more common because of the combination of interaction. But again for the right UI abstraction, it is quite more expected to act on press, play music on a piano, take a picture, starting/stopping video.

If you have functionality for both clicking and dragging UI elements, then act on press just doesn't work or make sense. Act on press also makes it much more likely that you accidentally click on things you didn't intend to. Objectively easier to code for, but I also don't think it's what people expect or are used to. I've also read of a few 'scenarios' where people/users get the feeling a button didn't actually work properly if the action happens too quickly, as your brain can kind of play tricks on you and it can can feel like the actual 'physical click' happens after the actual action does. Also the issue that if a button press changes the UI/opens a new window/etc, now there might be a new button where you're currently clicking...

Potentially breaking functionality should be hidden behind an additional confirmation prompt anyway.

I think this would mean users that require screen readers would not have the opportunity to listen for the button label text. Might be an accessibility anti-pattern.

Yeah ditto to what others are saying. For critical non-game applications, it makes sense to retain the on-release behavior, as an added check against accidental inputs. Imagine a touchscreen app for banking, easy to see why this could be problematic. That said, maybe other confirmation systems make more sense... tying such safety measures to a UI idiosyncrasy fails to call attention to the pitfall -- it simply brushes it under the rug by ignoring all on-press behavior. Meanwhile, in games, there are so many examples of extremely popular games that nevertheless get this wrong. Dark Souls/Elden Ring/etc all use an on-release/on-hold system for their combined dodge/sprint buttons, and that negative edge behavior causes inexperienced (and/or inattentive) players to miss the timing for a roll despite actually pressing it in time. It's unintuitive, and it's a bandaid fix to allow multiple functions with one button. Whenever timing is critical (as is the case in ALL UI, because the user's time is valuable), on-release should be avoided. And to the extent that it allows users to "un-click", it merely serves as a confirmation check that could be implemented more robustly in other ways.

The post didn't imply VR at all at the start - I can understand act on press in the situations described in the post too - keyboards, VR interactions... But regular old desktop UI you click with a mouse? I'll die on the exact opposite hill - keep act on release. This should work on a case-by-case basis tho, in two ways: First, implement both interactions for generic UI frameworks/libraries so the developer can choose which UI element acts in what way. Second, give your user the option to change this if they so wish. Everyone wins. I'm all for having a broader set of tools, I just don't think one should enforce one or the other just because of personal preferences.

The answer is very simple. When the action does an action that has an immediate result, _even if it is reversible,_ then act on release. Examples: - options inside select boxes - Like/Subscribe/Post or cancel comment/Download buttons - anything that results in (real) navigation - anything that creates a modal But when it is a simple UI element that just shows you more options, then act on press. Examples: - opening select boxes - expanding collapsing text - hamburger menus - sidebar buttons - anything that has a popover - switching tabs-as long as the state is unchanged when switching back

Fun fact, youtube video track bar is act on press!!

Actually, the act on release is there to allow double click.

seems to be web developers in the comments rn

@stephanenathan8034

Ай бұрын

hey I watch your stuff.

@theodorealenas3171

Ай бұрын

They seem attacked, or they're scared to go against what's usual. They even bring up arguments Carmack addressed, like they throw random things at him and run away

Interesting, I didn't know it was called act on press/release.

I feel like it might be time to write a config file library. For most uses, John Carmack is absolutely correct about act-on-release versus act-on-press, but it should ideally be configurable without recompiling. The reasoning is because there are times where AoR is the preferable behavior, but not every time, and not every button. My suggestion would be to just add a field to everything that needs the behavior to be configurable into a configuration file, say as "[item] act_on = release" or "[item] act_on = press". Of course, you might well opt to just use an existing library, and if you do I'd suggest using TOML. My own config file format that I've been using for years now is more or less the same, but I don't do the weird subsection thing that TOML does.

Only watched the thumbnail: yes! Don't insert lag into interactions. Make undo easy.

I've been doing act on press for almost a decade now. I'm surprised people are only talking about this now.

smart control+f, new nightmare unlocked

I recognized Greetings from Pilot Red Sun in an instant 0.03 seconds hahah, iconic.

I was going to say consistency with other apps is more important, but nothing else is consistent anyway, and Chromium's UI has a mixture of on-press and on-release buttons that I almost didn't notice.

@rabbitcreative

Ай бұрын

Context over consistency. Always.

It’s funny the ctrl F rant. I recently tried the arc browser and it does exactly this it does llm search on the page when you do ctrl f.

I want the trigger on my gun in Doom to be act on press, but the button that commits a destructive operation to be act on release over the button. Game devs and real-world UI devs are not the same.

Maybe it is true for real time fast paced games, but absolutely not for any other application. And now I want to write a whole f-g essay "way Carmack is wrong"... Let start with: action on release allows user to experiment if they don't know how to use this specific application. It allows to drag-an-drop, long press and text selection in active elements to *exist*, he states. And consistency is a good design pattern also.

Ctrl+Z and fg to resume or kill %1 would be ideal imho. 36:51 gives you the "I'm really trying to cancel" signel?

I tend to click too fast to make event cancelling useful to me. I'm just conditioned to assume there's always a bit of lag when I click on something and it feels weird when there isn't so I prefer onrelease for that reason. Now if was playing a game and I was going through a menu I expect minimal lag so in that case I would prefer onpress.

28:10 : It does seem like on-press would be significantly better for on-screen keyboard keys. For on-screen keyboard keys, undo is very easy, you just hit backspace. And, on-screen keyboard keys are often rather small, increasing the chances of accidentally moving finger/pointer off of the key before releasing it. And, I think the study was done specifically for on-screen keyboard? So, as there are reasons to expect the result to hold in the specific case of on-screen keyboards, such that these reasons don’t apply to other things, I don’t think doubting that the thing holds for other things, requires doubting the results of the study. Edit: 28:42 ... I should have waited like 30 seconds more in the video before commenting..

Drag & drop? Why not just drag?

@GameBacardi

Ай бұрын

Drop & pickup is funnier

@doodocina

Ай бұрын

cuz u can't really drop drugs, yes

I feel like the graphical elements like buttons, it should be act on release. But for something like "Press x to jump" it should be act on press.

John Carmack also recommends Atlas Shrugged and said story in games is as useful as story in porn. He's done great things, but it's dangerous to idolize people and their shitty opinions as if they are infallible.

We do act on release so we can drag.

50:30 как же я понимаю. поиск по сообщениям одновременно пропускает сообщения, в которых написано буквально то, что ты ищешь, но при этом находит совершенно левые сообщения. А ещё вбивать в поиск сообщения об ошибках в поисках решения со временем стало тупо бесполезным

It's pretty simple right? Use either where they make sense to be used. What makes sense tends to be what most users are comfortable with. John Carmack is an exceptional person in both positive and negative ways. Making a world that feels "correct" to someone like him would alienate 99.999% of humanity.

I would say touch scrolling and drag and drop are non issues. Touch scrolling could be done with 2 fingers, and dfag and drop could just requure a hotkey

If you want to mimic a real button, act on click is the right way to go. Developers always want to "improve", just put a decent confirmation window if it's important, and if it's not important, why would you care ?

Its ironic the tweet mentions "game developers get it right " when the expectations of a user who's playing a game and a user who is using a utility are entirely different. Unintentionally launching a Nuke in sims isn't the biggest deal, but dispatching one in the real word would be. And you can't mix and match how different button behave based on their actions performance hit, because the user may not expect the difference in one buttons performance to another therefore misrepresenting their expectations when they go to click a button. Not to mention that level of inconsistency just leads to a sloppy bad user experience.