If you're a button, you have one job • Hacker News Board

Re: If you're a button, you have one job

#191

Post by madibo3156 » Sun, Jul 05, 2026, 2:18 PM UTC

niam wrote: post #187

One similarly egregious UX issue on the latest Android is that pressing buttons in the dropdown tray doesn't give any feedback until the action is complete. I can press the "turn on WiFi" button and receive zero haptics or visual indication that the phone registered my tap, for over a second, and THEN it will decide "okay! let's shake the phone and change button color now". And if you have a tray button that needs to…

That's a good example of bad UX, and, in a way, counter to the article.

It sounds like Android needs a middle state indicator. When your action is in a pending state, the state indicator should not be the same as the previous state. A common pattern is to show a pending animation.

While this animation is running, what should happen if the user presses the button?

Re: If you're a button, you have one job

#192

Post by sokoloff » Sun, Jul 05, 2026, 2:26 PM UTC

xigoi wrote: post #95

Telaneo wrote: post #87

Earlier quoted context omitted.

New people are born every day.

The newly born people grow up in a world where computers are already commonplace, so they don’t need to get used to them.

Wild take. They’re not born “used to them,” so at some point they quite literally need to get used to them…

Re: If you're a button, you have one job

#193

Post by StilesCrisis » Sun, Jul 05, 2026, 2:33 PM UTC

jmyeet wrote: post #174

mrkeen wrote: post #145

Earlier quoted context omitted.

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.…

> A dev might think you can just catch and log the exception. Doesn't fix it. You've just succinctly made the argument against checked exceptions FWIW (which I agree with you on). Anyone who has used Java in anger (is there any other way?) will be familiar with: try { doSoemthing(); } catch (CheckedException e) { logger.error("Didn't work", e); } Fault tolerance is general is terrible in most software. One of my bigg…

As much as I agree with the spirit of your post, standards did in fact change after the Therac-25 incident. That was nearly 50 years ago, after all! There are very high quality bars for medical equipment.

Re: If you're a button, you have one job

#194

Post by mrkeen » Sun, Jul 05, 2026, 2:34 PM UTC

jchw wrote: post #189

jmyeet wrote: post #174

Earlier quoted context omitted.

> A dev might think you can just catch and log the exception. Doesn't fix it. You've just succinctly made the argument against checked exceptions FWIW (which I agree with you on). Anyone who has used Java in anger (is there any other way?) will be familiar with: try { doSoemthing(); } catch (CheckedException e) { logger.error("Didn't work", e); } Fault tolerance is general is terrible in most software. One of my bigg…

IMO a lot of these problems come down to the same root cause: we are not fully enumerating and reasoning about failure cases. Let's say you want to retry a network request. It's... A bit more complex than it seems, right? Firstly, you need to know exactly what type of error you ran into. Some errors aren't really recoverable. Maybe a programming issue occurred and you are constructing an invalid URL and the HTTP clie…

I don't disagree with anything in particular here, but other developers might fall into a trap with:

  we are not fully enumerating and reasoning about failure cases.

This might put (or keep) a developer in the mindset that they can code a series of imperative instructions to build their minimal viable product, and then come back and tighten things up later.

I expend all my effort in avoiding 'doing two things'. It's bloody difficult, but since I've come around to thinking that recovering from 1-of-2-things-failing is probably impossible in most situations, doing it the bloody difficult way is easier.

Re: If you're a button, you have one job

#195

Post by mrweasel » Sun, Jul 05, 2026, 2:40 PM UTC

simonklitj wrote: post #52

bloak wrote: post #50

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…

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.

I've only worked for one company that actually did proper QA testing. It's expensive and time consuming and often the main functionality is okay, so many just skips QA altogether.

It is probably daily that I encounter products and procedures where I can see that a given scenario is kind of a an edge case, but not an unforeseeable one. Given the scale of many things, edge cases happen pretty frequently and with ever more ridged organisations, lack of customer service, human interaction and a quest for ever more cost savings, hitting an edge case can be everything from frustrating to catastrophic for a person.

Generally I think we, as in humans, need to slow down.

Re: If you're a button, you have one job

#196

Post by lebuin » Sun, Jul 05, 2026, 2:42 PM UTC

chrismorgan wrote: post #166

inigyou wrote: post #161

Earlier quoted context omitted.

Then it should light up when the request is acknowledged, and stay lit up until the elevator arrives. But wait, there's more: when the elevator arrives until it leaves, the button should flash or change to a more prominent color. Why? Because imagine someone presses up and someone else presses down, and the elevator arrives going up. If the up button switches off at this point, now only the down button is lit which c…

Perhaps we’re not talking about the same thing. What I refer to has the button light up while you bump it, and then go dark again, whereas if you press it more deliberately, it stays lit (and takes effect). This can apply to the buttons inside or outside the lift.

It does sounds somewhat reasonable on paper. But some of the crosswalk buttons in Belgium have this as well, and it's really jarring. You press the button, see the light go on and look away to look at the traffic light and wait for it to turn green. Except 20 seconds later you look back and the indicator light is off again. I feel very strongly that the indicator light should only turn on when your press has been registered.

Let's say you tell someone to do something, and they say "ok". But when you ask them later whether they did, they say "oh no, I just said ok to indicate that I heard you, not that I was going to do something about it." That doesn't make any sense. The indicator light has the same function. Going on and then off again is a violation of basic communication protocol.

Re: If you're a button, you have one job

#197

Post by xigoi » Sun, Jul 05, 2026, 2:43 PM UTC

sokoloff wrote: post #192

xigoi wrote: post #95

Earlier quoted context omitted.

The newly born people grow up in a world where computers are already commonplace, so they don’t need to get used to them.

Wild take. They’re not born “used to them,” so at some point they quite literally need to get used to them…

The point is that a computer will just be another thing for them to learn, not a replacement for other tools they’ve been using for tens of years. Therefore, the computer does not need to look like those other tools in order to make sense to them.

Re: If you're a button, you have one job

#198

Post by et1337 » Sun, Jul 05, 2026, 2:48 PM UTC

[dead]

Re: If you're a button, you have one job

#199

Post by Someone » Sun, Jul 05, 2026, 2:59 PM UTC

efficax wrote: post #182

mcv wrote: post #94

Earlier quoted context omitted.

Debouncing exists for a reason. Sometimes when a button is clicked twice, you want it executed twice, sometimes you don't. Distinguishing which is better in which situation is not trivial. At the very least, you should consider which is appropriate for which situation, what if, in your UI, for some buttons one is the obvious choice, for others it's the other, but for some it's not so clear, and both behaviours are de…

a button that debounces requests should be disabled until the action is complete instead, so you can only click it once until it is ready to be clicked again. debouncing button clicks is a design failure (it makes more sense for things like requests that happen during typing, where you don't want to stop the feedback)

There always will be time between the first click and the time the button gets disabled and even more time before the visual representation of the button gets updated to reflect that. Keeping that time so short that it is impossible for a human to click the button again can be very hard.

It would help if GUI elements had a property “automatically disable on click”, removing the need for the “on click handler” to disable the button (in exchange for adding the need to explicitly re-enable it).

I don’t remember seeing GUI libraries that do that, though.

That probably is because it would confuse users if buttons visually get disabled when they click them.

So, the best answer is to visually keep the button enabled, but ignore rapid further clicks. That’s debouncing.

Re: If you're a button, you have one job

#200

Post by stavros » Sun, Jul 05, 2026, 3:02 PM UTC

inigyou wrote: post #161

chrismorgan wrote: post #157

Earlier quoted context omitted.

I have long presumed that sort of thing to be deliberate, avoiding activation on accidental bump.

Then it should light up when the request is acknowledged, and stay lit up until the elevator arrives. But wait, there's more: when the elevator arrives until it leaves, the button should flash or change to a more prominent color. Why? Because imagine someone presses up and someone else presses down, and the elevator arrives going up. If the up button switches off at this point, now only the down button is lit which c…

But then you might tap the button and think it's broken, because it does nothing. The light means "this button works", not "your desired action has registered".

I guess you might want to fade it from red to green (red being "this works" and green being "it'll do what I want"), but I don't mind the holding-down behaviour. The only problem is that you can never know how long you need to hold it down for unless you stop holding it.