If you're a button, you have one job
nozzlegear
99 points
26 comments
July 05, 2026
Related Discussions
Found 5 related stories in 882.4ms across 14,015 title embeddings via pgvector HNSW
- If you want to create a button from scratch, you must first create the universe treve · 56 pts · July 16, 2026 · 51% similar
- You are not your job jryio · 111 pts · March 22, 2026 · 46% similar
- If more than 50% press blue, everyone survives. Red pressers always survive iuvcaw · 49 pts · April 26, 2026 · 43% similar
- Doing Nothing at Work Sukram21 · 62 pts · June 08, 2026 · 40% similar
- You can just say it antirez · 287 pts · May 29, 2026 · 40% similar
Discussion Highlights (10 comments)
tangenter
I don’t remember anyone resigning from Apple because of a particular shade of blue. So maybe they have that going for them idk.
kazinator
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.
QuercusMax
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.
sockbot
The real article getting to the point the author is trying to make is this one https://aresluna.org/show-your-hands-honor/
kazinator
We like buffering of keystrokes or gestures when the system is completely reliable, exhibits reasonable latency and low jitter in its latency.
projektfu
In the Google photos app (Pixel 10) there is no animation, the rotation just happens immediately and there's no button press to buffer.
notpushkin
The author says: “Now, I’m going to exaggerate the problem a bit and tap 90-degree rotation quickly eight times.” I was wondering why the Nothing one stuck upside down after that, and expected a rant about Android not registering all taps or something. But the article got ahead with explaining how the Nothing’s solution was better. Huh? The iPhone was eight taps. The Nothing was six . (Yeah, I could have noticed it while watching, but I was situationally incapacitated; namely, I’ve just waken up.) --- Edit: I’ve rewatched it in 0.5× and the Nothing was eight taps after all, too. Author’s point was, indeed, that all taps should register regardless of what animation state is, and Nothing doesn’t do that. Sorry for the confusion! --- Regardless! I still find the iPhone one more pleasant to look at, because the animation doesn’t stop. But if you press quickly enough, I guess what they could do is animate until the taps stop, then: • if the image will arrive to the desired state: finish up the current 90°; • if it’ll still be 90° away: finish up then show one more 90°; • if it’ll be 180° away: flip it upside down, then finish up the current 90°; • if it’ll be 270° away: flip it upside down, finish up, and show one more 90°. But that’s not a very practical thing to implement I suppose.
anilgulecha
Camera app should negate the need. most pictures are of people and scenary, and 99.99% of the time the intent is to take the photo in the right order. Simple totally offline ONNX models exist, whcih should make it trivial to categorize the right orientation. Acceleometer/magnetometer can feed this, but should not be the default. Just do this and avoid the hassle of rotating at all!
OneLessThing
It's not so simple. There are times where you intend to tap one thing and something else appears underneath your finger instantaneously. So sometimes while rendering a layout you want to stop accepting input.
Topfi
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.