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

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

#161

Post by inigyou » Sun, Jul 05, 2026, 12:36 PM UTC

chrismorgan wrote: post #157

tgsovlerkhgsel wrote: post #100

Earlier quoted context omitted.

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.

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 clearly signals the elevator is going down, which is wrong.

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

#162

Post by embedding-shape » Sun, Jul 05, 2026, 12:37 PM UTC

amelius wrote: post #156

embedding-shape wrote: post #53

Earlier quoted context omitted.

I'm no longer the Apple/Mac/Jobs fan-boy I once was in my earlier days, but I do miss the Apple presentations that felt like they were run by a human being wanting to show off cool stuff. I couldn't even finish the last Apple presentations as it all feels so stiff, inhuman and run by suits, they all seem like robots scared of diverging from the holy script who will get fired if they display emotions and humanity. Off…

Apple keeps solving the same old problems. Why are we still talking about how well their buttons behave?

If anything it seems to be getting worse with each iteration for long time. I guess I'm cautiously optimistic they'll get back closer to their roots with some high-level change, but really don't care that much about it these days either...

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

#163

Post by seanalltogether » Sun, Jul 05, 2026, 12:37 PM UTC

inigyou wrote: post #119

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?

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.

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

#164

Post by chrismorgan » Sun, Jul 05, 2026, 12:43 PM UTC

greatgib wrote: post #135

padolsey wrote: post #41

The author suggests they want three clicks at any pace to always == the same functionality, so they can whiz through their photos and rotate each predictably. Fair. > And it would be so much more predictable and pleasant if you could just tap the button three times at any pace you wanted without thinking, without paying attention, without getting your UI blocked by an animation that no longer helps you. They cite acc…

I totally agree, even not going as far as a Parkinson case, if you already so old and not too old persons use phones and touch screens, you will see that very often it is complicated for them to click on the small button at the right place and to have the feeling that "they have clicked". So, for me, on the argument of about accessibility, the Nothing Phone behavior will work a lot better I think. In their mind they…

Around 2011, my grandfather with Parkinson’s and deteriorating eyesight received an iPad from family. They didn’t use it for much, mostly video calls and reading the Bible, with the text steadily getting larger and larger (up to letters being more than 5cm tall towards the end). It was funny just how good it was if an app only supported iPhone and not iPad, because then the iPad would scale it up to double physical size.

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

#165

Post by bayindirh » Sun, Jul 05, 2026, 12:44 PM UTC

inigyou wrote: post #160

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

Why can the two things even fail at all?

A programmer had a problem, so they decided to use threads.

Now they have at least two problems.

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

#166

Post by chrismorgan » Sun, Jul 05, 2026, 12:49 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…

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.

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

#167

Post by tomasphan » Sun, Jul 05, 2026, 12:50 PM UTC

crewindream wrote: post #120

ksec wrote: post #111

We ( including myself ) like to shit on Apple's regression of UX and software. Which is true, on all of their OS. But every time we look into alternatives, the others are so far off that even Apple has regressed 10 - 20% they will still be so far ahead of others. Google, Microsoft, Amazon, Netflix, Meta. Is there even one software company that does software UX well but not on Apple's platform?

I have only iphone, but from my experience, apple ui quality is just a huge myth nothing to do with reality. On average it is has same amount of crappy UI experience, just in different places.

How can you compare if you have only iPhone?

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

#168

Post by ryandrake » Sun, Jul 05, 2026, 12:50 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.

Not handling rare cases is the root of a lot of bad software. “Oh, this bug will only affect 1% of users. Don’t bother fixing it: we have features to cram.”

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

#169

Post by jamiejquinn » Sun, Jul 05, 2026, 12:55 PM UTC

seanalltogether wrote: post #163

inigyou wrote: post #119

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?

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.

[dead]

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

#170

Post by IdiotSavage » Sun, Jul 05, 2026, 12:57 PM UTC

slazaro wrote: post #146

arendtio wrote: post #125

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

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.

> But a button that works like that in a GUI would feel wrong.

No, it doesn't. It feels way more responsive.

My pet peeve is "stopwatch apps" which trigger on release instead of on press. When timing something where fractions of a second matter, most people won't realize that it triggers on release and tap down when they want to start / stop, adding some arbitrary delay until they actually release the button.