If you're a button, you have one job

nozzlegear 99 points 26 comments July 05, 2026
unsung.aresluna.org · View on Hacker News

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.

Semantic search powered by Rivestack pgvector
14,015 stories · 131,331 chunks indexed