If you're a button, you have one job

Join the discussion

• Hacker News
• It's interesting that old Windows apps would accidentally do this by blocking the main thread.

  They'd even give visual feedback - the button remains looking pressed until the click handler returns when the operation is complete!

  Maybe blocking the main thread isn't so bad after all?

  by inigyou
• Its a perfect illustration of the tradeoffs between synchronous and asynchronous logic. Synchronous logic allows for maximal consistency at the cost of wasting time. Asynchronous logic allows you to use time efficiently, but requires you to track all the different states you can be in simultaneously.
  by seanalltogether
• As a user, I much prefer a blocking UI thread to one that lets me spam clicks on the "rotate left" and "flip along vertical axis" buttons and then makes me wonder why the resulting image is not the flipped verstion of what I saw the moment when I clicked "flip". However, I do like being able to abort my operations, and a blocking thread does not let me do that.

  It might be quite a hard problem to determine which buttons should be disabled during which operations. One tricky candidate is the "safe" button. Should I be able to click it when the visual feedback I'm getting does not yet match the internal state of the application (which is what will be saved)? Should I be able to start further tasks when the save is still in progress? (If so, what if the save fails? Will I be able to roll back to the state before the attempted save and try again?)

  by zzril
• Are there times when, during a call, pressing an iPhone’s screen-on/off button will end the call, but other times when it will just turn the screen off?

  I still do not know the pattern, but I have on occasion inadvertently ended a call by using that button prior to placing my iPhone in my pocket.

  by odyssey7
• When on Speaker/hands-free mode, it just closes screen. They assume you wouldn't press lock button while against your ear, because it closes the screen automatically. The problem is that there's some bugs that keep the screen open sometimes, or you may use it in a quiet room as if it were on hands-free.
  by gobdovan
• The real article getting to the point the author is trying to make is this one https://aresluna.org/show-your-hands-honor/
  by sockbot
• Ok, we'll put that link in the toptext as well. Thanks!
  by dang
• Reminds me of the time I built a BabyButton, which was built in a way so that a baby could use it. Instead of the normal click behaviour, it was using the touchdown event, because that way the kid saw that something happened, and there was no problem with holding the button too long or moving the finger while still holding the button.

  Whether you should build systems for that age group is an entirely different topic, but I found it a good challenge to design something that fits the user's needs.

  by arendtio
• It's interesting that we're so used to the GUI buttons having that specific behavior of only triggering when releasing, even if you exit and enter the button area while holding the mouse button down, etc.

  IRL 99%+ of buttons work by just doing the thing as soon as you press them. But a button that works like that in a GUI would feel wrong.

  by slazaro
• One job doesn't really fit the button thing because a button has to do many things, only one of which is being clickable.

  Having feedback when clicked, feedback when hovered. A loading state, a disabled state, a mix of everything. That's also something I found very frustrating. Like if you take the example of a button that is tied to a service on the back end, clicking this button without any visual feedback doesn't tell you if that button was clicked or not. And if it doesn't have a loading state, you wouldn't know that. something is working behind the scene when you click this button so you would click at multiple times not knowing that it's still working behind the scenes.

  by othmanosx
• Just to go out on a wild tangent...

  buttons on simple hardware devices usually have many many functions.

  this button has a function. but if you are powering up and hold it, it does a different function. press and hold this button and while holding it press another button for something else.

  The most extreme example of this kind of thing I can recall is the anduril open-source flashlight firmware: an enormous number of functions on a one-button flashlight.

  example: https://budgetlightforum.com/uploads/default/optimized/3X/e/...

  or in text: https://ivanthinking.net/manuals/anduril2-manual/

  by m463
• This is literally the type of thing that caused the THERAC-25 disaster (https://en.wikipedia.org/wiki/Therac-25). Experienced users hitting keys faster than the app could process them, resulting in safety features being inadvertantly bypassed.
  by QuercusMax
• That's a great example of bugs in overcomplexity. The requirements were relatively simple, but they went for a full-on multitasking OS with all the complexity that entails.
  by userbinator
• Looking at the first comparison, I will admit, I thought the issue was with the iPhones example. The button and slider below the image disappear, then fade back in after each press of the rotate button, a behaviour I have seen on iOS across many applications that irks me to no end. The Screenshot app being a particular bug bear of mine.

  If you have a UX element that I will be able to interact with before and after an interaction, then keep it visible during the transformation, process, whatever. What UX gain is there in hiding these buttons during the rotation on the iPhone? It doesn't even look better, though appearance has been the altar that recent Apple software has sacrificed actual UX gains.

  Will agree with the author though that these taps need to be processed independent of animation.

  by Topfi
• I wish software apps had "tape-out rules" the way that computer chips do. Basically, when you design a computer chip, a program reviews the design and compares it against something like 300 pages of rules with stuff like "wires of X metal and Y metal can't be within Z distance of each other".

  We could make something similar for UX. Just a bunch of design pattern constraints that throw flags if you try to ship something with well established UX warts.

  by Taek
• I used to have a device with a physical button which, when you pressed it, would beep and add 30 seconds to the time. However, sometimes it would beep and not add 30 seconds, and sometimes it would add 30 seconds without beeping, so you always had to squint at the dim display to discover whether it had worked or not. I thought this must be a peculiarly bad design ... but since then I have lost count of the number of purely software buttons that somehow seem to replicate this broken behaviour: whether the button changes colour on the screen is somehow only loosely correlated with whether the action requested will take place. Why? How, even, have they implemented this?
  by bloak
• Another one I see is low end devices have a volume knob that instead of being a potentiometer are a rotary dial encoder so you end up usually only being able to adjust the volume as fast as it's sampled, which is slower than you want for example in traffic turning the radio down to hear stuff
  by calvinmorrison
• This is sometimes done intentionally to hide latency and make a UI feel faster - I certainly don’t like it though.
  by markatto
• I suppose a lack of testing and an assumption that the action will fail so rarely that it’s not worth accounting for? But yes, such patterns make it hard to trust and efficiently use an interface.
  by simonklitj
• The color change of the button shows you succeeded in pushing it. If you don't do this instantly most people are conditioned to try again. This is especially valuable for people with reduced motor control. It is completely independent of whether that push is a useful input given the current state of the software. Obviously when well written software knows it can't accept the input it should have disabled the button, and even moderately well written software needs to provide a near instant feedback that the action is processing or has been cancelled.
  by ZiiS
• Bad programming. People who have experience with embedded programming knows that reading out a button usually means denouncing. At the speed a microcontroller can read out a button it will change it's state multiple times per press because of contact bounce. Meaning when a user presses a button the program sees off, on, off, off, on, on, off, on, on, on, on, on, on, etc.

  Now if you just naively read out the current state of the button and do something with it elsewhere in the program looping may be off or on randomly.

  It is not hard to imagine if there is some other logic (or e.g. a rate limit) on the 30 seconds and on the beep that these would see different slices in time of the button. Congrats you built a button-debounce based RNG.

  Physical buttons can be surprisingly complex if you don't rely on someone else's driver. The correct solution is to debounce the button, that can be done either in hardware (too expensive, so rarely done) or in softeare, by e.g. averaging the last 50 reads and wait till the majority is either off or on.

  This should be common knowledge for embedded programmers, but every noe and then you will see someone who has never heard of it.

  by atoav
• I notice this pretty consistently with elevators: If you press the button for a short amount of time, it visibly lights up while pressed but doesn't actually register the button-press.
  by tgsovlerkhgsel
• I call it the "doing two things" problem.

  Your write imperative code, which issues two commands, both of which can fail independently.

  There are plenty of ways to pretend to 'deal with it'.

  Firstly it will just pass all tests, so most devs can stop thinking about it right away.

  A dev might think you can just catch and log the exception. Doesn't fix it.

  You could run the code in prod for a while, see if it goes wrong. It will, at which point the dev will try it again, and it will probably work the second time, so they can stop thinking about it.

  There was a big outbox pattern discussion a couple of days ago (split thing 1 into two halves, and do them atomically, leave thing 2 as an exercise for the reader.)

  I think the reason you encounter this problem in the real world is that devs just exist in some quantum superposition of "it won't happen" and "I fixed it" and "it can't be fixed".

  by mrkeen
• > Why? How, even, have they implemented this?

  This is really common because of two design features that most UI frameworks share:

  - The code that changes the color of the button is an internal part of the "button" component, so that people don't have to individually implement it on every button. But this means that it's kind of disconnected from the code that actually performs the action. If the "on click" handler has some last-ditch check that aborts the action, like the "don't rotate the image if it's in the middle of the rotate animation" check from the article, often there's no way for it to tell the button to cancel the color change. (And conversely sometimes the "on click" handler can fire even if the color change animation doesn't play correctly.)

  - Buttons usually change color when you press down the mouse button, but only perform the action when you release the mouse button. Sometimes this is used to intentionally give you a chance to cancel the action at the very last minute by dragging your mouse off the button while it's still held down (or, on mobile, to e.g. reinterpret your interaction as scrolling instead of clicking), other times it just creates more opportunities for something to happen that prevents the action from working after the color change has already happened.

  by csande17
• People often forget that animations serve purely a supportive role and do not exist for the purpose of having animations.

  They are there to mask loading times and ease from one state into the other. That's why we have them.

  This knowledge eventually got lost (figuratively speaking) and now we have code that needs to wait on the animation to finish.

  Another amazing example of cargo culting.

  by hypfer
• I have disabled all animations on my Android, and it feels so much nice. I particularly HATE that one animation where the whole screen stretches if you try to overscroll.
  by earth-tattoo
• Apple used to know this. They've had animations after items were dismissed, but avoided animations before showing an item.

  Old Apple understood design is more than making things pretty. The glassy Apple is all about how it looks in a demo.

  by pornel
• I find animations to almost always be gratuitous. I disable them in all cases where the app or system gives me that ability.
  by SoftTalker
• They aren’t purely for that, they also contribute to how an application feels to use in a creative manner.
  by antihero
• > to mask loading times and ease from one state into the other

  I'd expand on this: used well, they show the user than a state change is happening directly because of a particular action of theirs, and hint at how they might reverse or modify it.

  In fact I'd disagree with masking. If something appeared instantly with no hint as to why, that is a distinct anti-pattern on a touch screen.

  by alexdbird