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.

But I also hate the "you had one job" meme and want to argue against its mindless usage. Most of the time, when people do the "you had one job" thing, it's false. And that's true most of the time in the case of buttons, too. In a typical user interface, a given button has some combination of these jobs:

* Communicate what action will occur should the button be pushed.

* (Sometimes) communicate the current status of some aspect of the system (e.g., often a button is used to enable/disable a mode, and the button itself visually conveys what the current mode is).

* Execute the intended action upon clicking.

* (Sometimes) communicate that the command has been received and is being executed (e.g., in the OP, the button might disable itself while animating the rotation in order to avoid the confusion the OP complains of).

This is a good example of thinking through the user's intention and accessibility states. We need to capture clear user intent first, then decide on the UX behavior. Changes like these help all users.

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

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.

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.

Whether you should build systems for that age group is an entirely different topic, but I found it a good challenge to design something that fits the user's needs.

One more ancient trick: back when computers were slow I would always ask myself why the data is not already in the desired format.

For example: Today you might have data in a json and turn it into a row of divs. You could store the data as a file with a row of divs which would make it a pain working with it on the backend. But on the front end you wouldn't have to parse it.

The phone doesn't modify the image but it changes the image orientation.

This is much faster but all other operations would need to work with it and when eventually served in a browser all the 100 000 viewer clients would have to rotate it themselves.

I won't argue it's wrong but it shifts complexity from image rotation to image editing and viewing.

It seems strange to add "real" rotation to the ui but the phone app is the industrial standard for image editing.

I still do not know the pattern, but I have on occasion inadvertently ended a call by using that button prior to placing my iPhone in my pocket.

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?

One thing I learned from her is that if you want someone to stop doing something you don’t punish them, you ignore them. No response.

Now that I'm wondering. How does iphone mitigate this problem?

It's very rare that animation is not blocking further user actions. No surprise animations are tricky to program - they're very async in nature. Designing animation system that doesn't leak into the rest of application logic code is a no simple feat.

Google, Microsoft, Amazon, Netflix, Meta. Is there even one software company that does software UX well but not on Apple's platform?

Following the exact "best practice" in the article, the iPhone lock screen has this issue. Say your password is 1234 but you accidentally type 11234. What the iPhone will do is see 1123, the pause to tell you you failed, then enter 4. Now you, having muscle memory, will type 1234 (your password). But iPhone kept that 4 so it sees 4123 then pauses to tell you entered the wrong password, then adds the 4, and you type 1234 again, which again it sees 4123.

Finally, frustrated, you pause and press delete or take some other action to reset the lock screen and this time it works.

This has happened to me countless times since iPhone had a lock screen.

The better UX would be to clear the that after the error which is effectively what the Nothing Phone is doing with the photo rotation

I agree 100% with the article that for photo rotation it should do what the iPhone is doing. Conversely, it's wrong thing to do on the lock screen.

Sometimes I log into my big Windows machine at home with RDP from out of the house to post photos to my socials, like

https://mastodon.social/@UP8

and with a folder with a few hundred images in it is is awkward to use the official file chooser dialog because it is based on modern UI toolkits and practices which are wasteful and slow over the net. It is much easier to use XnView MP because it is based on an old widget set which isn’t flashy.

Similarly I find myself impressed with the old Adobe apps like Photoshop and Illustrator because, sprawling as they are, they come out of an old time when they were expected to work on machines with a fraction (1/2000 of the RAM!) of the capacity of modern machines and there is just less junk. Adobe recently took the “(legacy)” label off “Save to Web” because that ancient feature alone goes a long way to justifying the creative cloud subscription.

And if you have a tray button that needs to e.g reach over the network to a HomeAssistant instance that needs to itself reach out to some fuckass IoT vendor server, you may as well not expect any sort of feedback before you close the tray.

Also I work in XR and rely heavily on hand tracking and I'm precisely trying to use that accident so re-consider what does typing mean without a keyboard. How can one use hand tracking in XR as input without relying a virtual keyboard, which is so slow and lacks tactile feedback.

Anyway, all this to say yes, ours hands are impressively precise, fast, flexible. We take them for granted but it's definitely worth spending a bit of time training them, considering the interfaces at different level, ergonomic, physical interface, firmware, then the software with its UI.

When they're off, they don't blow any air so it would make sense to me to decide that the button to turn them on is the one that controls how much air it blows. It goes from 0 to 1 to turn on, so you just learned that that button changes how much air comes out of it.

But no, most of them do the opposite. So, you turn them on with the temperature control. The action is: no air, yes air, air gets super-hot if you keep pushing the button.

I can't find any modern air dryers where they get this right.

I almost always need to rotate photos 90⁰ to the right, so I have to tap that button three times. Apart from that, if I have only one way to rotate my photo, clockwise seems more intuitive to me anyway.

iOS is no better. Sure everything is intuitive but it's going to get a redesign so next year you are going to have to learn everything from scratch or a feature you use often will just break.

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.

No interface should, on a regular basis, contain buttons that, if pressed -- harm the computer and other computers near it.

And of course, this is links in modern email.

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.

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!

Better post an overview of everything a good button should do (no it is not just one job).

Even better, post an overview of good GUI design in general.

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.