[HN Gopher] Act on Press
___________________________________________________________________
Act on Press
Author : uxcolumbo
Score : 74 points
Date : 2024-05-23 19:07 UTC (3 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| uxcolumbo wrote:
| 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.
| taeric wrote:
| 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 wrote:
| 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.
| taeric wrote:
| 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 wrote:
| 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.
| taeric wrote:
| 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 wrote:
| 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.
| phailhaus wrote:
| He specifically does not call out games:
|
| > Game developers, with simple UI toolkits, tend to get this
| right more often
| taeric wrote:
| 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.
| mvdtnz wrote:
| This isn't about which events are exposed by a UI toolkit,
| it's about which events are responded to in application
| code.
| numpad0 wrote:
| 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.
| N_A_T_E wrote:
| 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.
| Kiro wrote:
| > 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?
| constantcrying wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Kiro wrote:
| 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?
| uxcolumbo wrote:
| 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.
| constantcrying wrote:
| 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.
| uxcolumbo wrote:
| 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.
| constantcrying wrote:
| >Getting another popup to confirm the action would be
| annoying.
|
| Every bank system or stock trading app I ever used worked
| that way though. Giving an order summary seems like an
| obvious solution, giving the user a way to check and to
| unambiguously opt out if there is a mistake.
|
| Buttons aren't there to be cancelled mid press, the
| interaction makes very little sense.
| uxcolumbo wrote:
| On my banking app I get a review screen as you described
| and I wouldn't be happy if the submit action would be
| triggered on press, because I'm already used to
| confirmation actions to be triggered on release.
|
| And just look at this comment thread, quite a few are
| used to this as well, so changing it would upset those
| users. It's also not a repeated action, so you won't
| really notice the difference that much compared to
| pressing buttons on a virtual keyboard.
|
| For non committal action button as per the examples above
| - yes use on press.
| constantcrying wrote:
| 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 wrote:
| UIs have worked this way since, basically, the very beginning -
| long before touch devices were a consideration.
| ibejoeb wrote:
| 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.
| 542458 wrote:
| 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...
| casperb wrote:
| 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.
| ZiiS wrote:
| Odd example as chess is often played with rules that forces you
| to move a piece you touch.
| Retr0id wrote:
| It is, and as an amateur player I find it a very frustrating
| rule to play by.
| abtinf wrote:
| https://twitter.com/ID_AA_Carmack/status/1787853145197904063
| aaomidi wrote:
| Yeah if that memory sticks around, then its probably a
| core/foundational one.
|
| John is just outright wrong.
| bmitc wrote:
| He also isn't making any sense. Why would someone keep in
| memory all the times something did what they expected? I am
| absolutely certain that if all buttons were act on press,
| there would be quite a few painful memories. Every time I
| encounter act on press it sends me.
|
| This is a typical engineer scenario of trying to reason
| something as if it is a scientific or engineering fact when
| in reality it is just a massive personal preference.
| aaomidi wrote:
| Literally ignoring the accessibility aspect of this too.
| People have shaky hands folks!
| jagged-chisel wrote:
| 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 wrote:
| See also "Never use a warning" (2007):
| https://alistapart.com/article/neveruseawarning/
| tialaramex wrote:
| Yes. Humans experience regret, "consent" is mostly a trick
| we use to get people who experience regret to blame
| themselves, not us, for what happened.
|
| We should prefer (and in software this will almost always
| be possible) to _undo_ the regrettable action instead of
| demanding consent.
|
| In some cases we can do even better and prevent the regret
| itself with "Brick wall UI". Brick wall UI is a design
| where the thing that you definitely don't want to do isn't
| possible. As designers we have to put more effort in to
| ensure that this only arises where it's genuinely never
| what you wanted to do, otherwise it's just incredibly
| annoying.
|
| The idea in Brick wall UI is that the user's experience is
| potentially, especially initially, the same frustration as
| if it was broken. Why won't the barrier open so I can drive
| my truck under the bridge? Why can't I use my login token
| to access this banking site and see my transfer details?
|
| And maybe, eventually, sat at the Brick wall UI, the user
| realises why and is glad. "Oh! My truck won't actually fit
| under the bridge, I just avoided an expensive mistake" or
| "Wait, this isn't my bank it's fakebank.example, it's a
| bloody phishing scam". Or maybe they don't, for hours, or
| days, or weeks, but since it was _never correct_ that 's
| actually fine.
| pseudalopex wrote:
| Undo should be standard for act on press and act on release
| flows.
| hresvelgr wrote:
| 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.
| parasti wrote:
| 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.
| Toutouxc wrote:
| 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 wrote:
| > 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 wrote:
| Negative time delay?
|
| "What's expected of us" by Ted Chiang:
|
| https://www.nature.com/articles/436150a
| Rygian wrote:
| They might have doped their silicon with
| https://en.m.wikipedia.org/wiki/Thiotimoline
| amanzi wrote:
| 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...
| numpad0 wrote:
| 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.
| xnx wrote:
| 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 wrote:
| 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.
| Jtsummers wrote:
| 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.
| bmitc wrote:
| The aren't the same thing though.
| yencabulator wrote:
| You can press an elevator button part of the way, without
| triggering it.
| jordansmithnz wrote:
| 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.
| abtinf wrote:
| 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 wrote:
| > 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.
| jayd16 wrote:
| 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.
| AlphaWeaver wrote:
| 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.)
| abtinf wrote:
| How about register the action but start a timer to allow
| cancellation?
| tshaddox wrote:
| 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 wrote:
| 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 wrote:
| 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.
| divbzero wrote:
| 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
| yencabulator wrote:
| SvelteKit does this by default for in-app links, but it's still
| just preload, not actual activation. Actual navigation happens
| on release.
| abtinf wrote:
| Carmack wasn't kidding when he said "this always gets brought up"
| in reference to dragging to undo actions. Lot of comments here to
| that effect.
|
| > Yes, this always gets brought up, but it is exceedingly rare in
| practice -- everyone has a memory of the couple times they
| carefully canceled a press, but they don't factor in the
| thousands of times they didn't cancel an error, or the hundreds
| of thousands of times they hit a button correctly.
|
| https://twitter.com/ID_AA_Carmack/status/1787853145197904063
|
| > A related UI principle is "make everything easy to undo",
| whether it is navigating back to where you just were, or
| undeleting a file. Don't use it as an excuse for act-on-release,
| or a modal confirmation dialog. Just do it, but allow it to be
| un-done. 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.
|
| https://twitter.com/ID_AA_Carmack/status/1787859646104928405
|
| > Everyone talking about being able to abort actions -- consider
| how highlighting the control when the cursor/pointer enters the
| hit box, then acting on press gives you the same two stage
| commit, but without the delay to release. You can't do it on most
| touch screens, but for mouse/VR it is the winning combination for
| any control that isn't part of a view that needs drag scrolling.
|
| https://twitter.com/ID_AA_Carmack/status/1787978078267806009
| teraflop wrote:
| > A related UI principle is "make everything easy to undo",
|
| But of course, there are plenty of actions that are
| _fundamentally_ impossible to undo, such as sending an email.
|
| So either you make those actions triggered on mouse-down, which
| means they're easy to do by accident, or you make them
| inconsistent with the rest of your UI.
| whstl wrote:
| ...or just delay sending the email by a few seconds, like
| lots of clients currently do.
| DaiPlusPlus wrote:
| That works for email, but less-so in Slack or IM in
| general.
|
| I did once play with a hacked-on delay-send setting, but
| any delay must be long enough to allow you to register
| making a mistake first, e.g. 3 seconds) but when it's that
| long it ruins spontaneity and the rapid back-and-forth
| experience when chatting away - in that situation I
| definitely prefer send-on-button-up, not send-on-button-
| down.
| Bjartr wrote:
| > there are plenty of actions that are fundamentally
| impossible to undo, such as sending an email.
|
| That's just a lack of imagination. Gmail and others allow
| undoing a misclicked send no problem. In cases it doesn't
| matter to the user if the action in practice doesn't happen
| exactly immediately, delaying it a bit while instantly
| providing feedback in the UI gets you the best of both
| worlds.
| edave64 wrote:
| Actions that are fundamentally impossible to undo should
| generally need confirmation anyways
|
| Maybe not for the email example, but the other comments
| already adress than
| charles_f wrote:
| 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 wrote:
| 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.
| bmitc wrote:
| 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.
| Jtsummers wrote:
| 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 wrote:
| 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.
| jayd16 wrote:
| 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.
| seabass wrote:
| 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.
___________________________________________________________________
(page generated 2024-05-23 23:01 UTC)