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

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

#171

Post by Brian_K_White » Sun, Jul 05, 2026, 1:02 PM UTC

inigyou wrote: post #114

mrob wrote: post #108

Earlier quoted context omitted.

>averaging the last 50 reads and wait till the majority is either off or on. This is a bad way to do it because it adds avoidable latency. A moving average is a low-pass filter. The switch bounce is better handled by hysteresis. Change state as soon as you see an edge, then ignore further edges until a timer expires, e.g. 5 ms, which should be enough for the bouncing to settle. A 5 ms timeout limits your repetition r…

They didn't say how often the reads are - 50 reads could be only 5ms.

No. Act on first transition. Cool down period following. You did not spot something everyone overlooked for 100 years.

There are other situations but not for a button. There are inputs that might be continuously noisy where a sliding window / ring buffer rolling sample is the only way to tell the difference between states. But we are talking about binary input controls actuated by a person, not a thermometer or O2 sensor.

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

#172

Post by [deleted] » Sun, Jul 05, 2026, 1:12 PM UTC

mrob wrote: post #116

inigyou wrote: post #114

Earlier quoted context omitted.

They didn't say how often the reads are - 50 reads could be only 5ms.

Latency is cumulative, so avoidable latency is never acceptable. Maybe the hardware will change. Maybe somebody will run your software in an emulator. That 5ms could be enough to push the total latency into the "annoying" level. And even with no additional latency, 5ms is perceptible in some cases anyway. Microsoft Research has a video demonstration: https://www.youtube.com/watch?v=vOvQCPLkPt4

[deleted]

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

#173

Post by dtgriscom » Sun, Jul 05, 2026, 1:15 PM UTC

mrob wrote: post #108

atoav wrote: post #72

Earlier quoted context omitted.

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

>averaging the last 50 reads and wait till the majority is either off or on. This is a bad way to do it because it adds avoidable latency. A moving average is a low-pass filter. The switch bounce is better handled by hysteresis. Change state as soon as you see an edge, then ignore further edges until a timer expires, e.g. 5 ms, which should be enough for the bouncing to settle. A 5 ms timeout limits your repetition r…

Lots of replies with good ideas here. The biggest question is that EMI resistance; do you really need to ignore brief closures? In the vast majority of situations, the answer is no.

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

#174

Post by jmyeet » Sun, Jul 05, 2026, 1:21 PM UTC

mrkeen wrote: post #145

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 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 biggest bugbears is network latency and transient failures in network requests that would be solved with a simple retry. But no, there's an incredibly lazy "Request failed" dialog to the user. That's the equivalent of the "log and silently swallow" pattern above. It can get a lot worse than that too. I have an app on my phone that will log me out and force me into a 2FA cycle if it hits a network timeout. Like.... WHYW?!?!?! Anyway, I digress...

This is largely a sotware issue. Control systems are built to handle these kinds of things. A traffic light can't accidentally show green in two directions. It's literally wired for that to be impossible because it's simply too important for it to not be possible. You constantly have to deal with faulty sensors so you have systems that will seek a consensus from 3+ sensors and, if that fails, it'll fail until you fix it.

But in software the standards just seem to be much lower even though it can be critical, even lethal eg [1]. Network interfaces should be fuzzed. Every IO operation should assume it can fail and be tested for when it does. Every IO operation should produce unexpected output. And it's simply cost-cutting and a lack of regulation that allows this sloppiness to persist. There should certainly be strict liability for any companies that allow this to happen.

[1]: https://ethicsunwrapped.utexas.edu/case-study/therac-25

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

#175

Post by WhyNotHugo » Sun, Jul 05, 2026, 1:21 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.

I think iOS has lots of refinement and polish, but still lots of ugly bugs and crappy UI. The others have the same crappy UI, but with no refinement and polish at all anywhere.

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

#176

Post by ssl-3 » Sun, Jul 05, 2026, 1:30 PM UTC

inigyou wrote: post #148

dutchCourage wrote: post #92

Earlier quoted context omitted.

This is a somewhat unpopular opinion here, however I do think flat UI can be done right and is well fitted to digital UIs. It's possible to have a flat style but have buttons that look clearly like buttons, and elements that have shadows and colors.

The original GUIs were all flat because that was the default. A button was a rectangle with text in it. A checkbox was a rectangle with or without an X across it. Pure black on pure white, no colors or shades. Windows used this style until Windows 95. Nobody seemed to have a problem with it. It was largely clear what was a button and what was a checkbox. In hindsight it was certainly uglier than the 95 style (maybe j…

I might be misunderstanding what you're saying, but: In the PC space, Windows 3.x definitely had some skeuomorphic elements. This presents most-commonly with the minimize and maximize buttons[1].

We have to go all the way back to Windows 2 in before we find flatness.

[1]: https://archive.org/details/msdos_win3_1

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

#177

Post by nstents » Sun, Jul 05, 2026, 1:31 PM UTC

I couldn't disagree more.

Every button has two jobs. One is to accurately convey what it will do. Two is to then do it.

Several of us can neither remember what your dynamic, curvy, arrowed, action lines do, nor can we extrapolate from them. They are an exercise in frustration. The nod to situational disability is appreciated, but most would have been useless without text descriptions.

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

#178

Post by codingdave » Sun, Jul 05, 2026, 1:35 PM UTC

nstents wrote: post #177

I couldn't disagree more. Every button has two jobs. One is to accurately convey what it will do. Two is to then do it. Several of us can neither remember what your dynamic, curvy, arrowed, action lines do, nor can we extrapolate from them. They are an exercise in frustration. The nod to situational disability is appreciated, but most would have been useless without text descriptions.

You are talking about the label on the button. The button does one thing. The label does one thing. You put the two together and you have UX.

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

#179

Post by krautsauer » Sun, Jul 05, 2026, 1:37 PM UTC

mproud wrote: post #35

How about when users accidentally click too much, or they believe the first click didn’t register? I am still reminded of a keynote where Steve Jobs was demoing how much faster PDF documents would display on the newer macOS. So he had engineers put a button in for him to click that would scroll through the PDF on the screen, and he accidentally clicked it more than once. Steve wondered aloud if it would scroll all th…

"How about"? These situations might exist, but this clearly isn't one. Two reasons:

1. "The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap […]"

2. There is a really good reason to tap this button 3 times in a row.

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

#180

Post by Joker_vD » Sun, Jul 05, 2026, 1:38 PM UTC

Gualdrapo wrote: post #22

kazinator wrote: post #5

If you're a button, you have one job: to transmit Morse code from the finger to the machine, Morse code representing a complicated POSIX shell command. And also to power down this entire one-button terminal with a 3 second press, power it up on any button press, with a firmware reset if powered up by a 30 second press.

The power button of my pc also has the job to tell wether the PC is turned on. So do bulb switch buttons that have a pilot light, and so on

Yeah, sometimes, when I am sitting before my computer and typing comments on the Internet, I have a thought: "Is my computer turned on?" With a quick glance under my table I can reassure myself that it is indeed on and continue using it. No idea what I'd do without that small blue LED.

The pilot lights are slightly more useful in those stupid cross-wired double switches that for some weird reason implement a sort of XOR (or sometimes XNOR because why not) gate for controlling a single light: if it's on, then the bulb is depowered and you can safely change it without turning off the entire power rail. But then one day the pilot light itself burns out...