If you're a button, you have one job

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 purely software buttons that somehow seem to replicate this broken behaviour: whether the button changes colour on the screen is somehow only loosely correlated with whether the action requested will take place. Why? How, even, have they implemented this?

People often forget that animations serve purely a supportive role and do not exist for the purpose of having animations.

They are there to mask loading times and ease from one state into the other. That's why we have them.

This knowledge eventually got lost (figuratively speaking) and now we have code that needs to wait on the animation to finish.

Another amazing example of cargo culting.

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 the way through twice… and sure enough, it buffered the process! He had to wait for it go all the way back up and scroll through a second time!

Steve saved grace by telling the audience that, even with moving through the document a second time, altogether it was still faster than PDFs had been in the last version of the OS.

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.

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

The thing is, I can imagine the complete opposite side of the argument, where someone with motor impairments or parkinson's, for example, ideally liking if their over-clicks were ignored if they'd already locked-in their intention.

It's tricky to get this stuff right.

The real article getting to the point the author is trying to make is this one https://aresluna.org/show-your-hands-honor/

iPhones had their share of animations interfering with functionality, one instance being calculator app showing false results when tapped quickly: https://robservatory.com/the-calculator-bug-persists-in-ios-...

There is a more general Android problem where it registers a single tap sufficiently to show a button press animation and vibrate and then ignores it because the tap wasn't held long enough.

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.

In the Google photos app (Pixel 10) there is no animation, the rotation just happens immediately and there's no button press to buffer.

This isn't unique to touchscreen interfaces. I have the same frustration when performing a sequence of keyboard commands and the OS can't keep up (or some other application or unwanted notification pop-up steals the focus).

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.

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.

We like buffering of keystrokes or gestures when the system is completely reliable, exhibits reasonable latency and low jitter in its latency.

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

I don’t remember anyone resigning from Apple because of a particular shade of blue. So maybe they have that going for them idk.

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!

I understand the design principle but I would argue it's a bad implementation principle.

Engineering attention is finite. Why would you spend time thinking about 8 clicks when most people will only need ~3?

Not all user-action possibilities are equally important, and if they are, then you better have infinite resources to spend on engineering.