If you're a button, you have one job

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.

I want to support the "what about debouncing" argument mentioned elsewhere; the author shouldn't just ignore this.

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

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?

Great point. So often I hear people talk about Apple as the hallmark of usability, but the reality is other systems do a great job too.

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.

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.

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.

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.

Reminds me of the time I built a BabyButton, which was built in a way so that a baby could use it. Instead of the normal click behaviour, it was using the touchdown event, because that way the kid saw that something happened, and there was no problem with holding the button too long or moving the finger while still holding the button.

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.

If the ui calls for it I take the current position of the element and the destination then change the current to be exactly in between repeatedly on a interval. That way it moves really fast and eases into position.

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.

Are there times when, during a call, pressing an iPhone’s screen-on/off button will end the call, but other times when it will just turn the screen off?

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.

It's interesting that old Windows apps would accidentally do this by blocking the main thread.

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?

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

My wife is a behavior analyst and I’m a game developer. We both watch people and try to figure out how why they are doing stuff and how to get them to do what we want.

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.

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's a problem with buffering tho. If the device's slow and unresponsive, and the user tapped the rotation button several times, it would be confusing if the rotation action happens 10 seconds after the user tapping the button. The user'd be left confused like "alright. So, has my input been taken?"

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

For me Apple's "hold the button until something happens" to turn on my iPhone is and always has been and always will be a FAIL.

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.

When I had my last Android phone (KitKat 4.4), best tip for increasing UI snappiness was reducing (or disabling) system animations. I still miss this option on most modern OSes, shells, apps, and websites.

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.

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 am puzzled (and irritated) why there is „rotate left” without „rotate right”. Does any of you know why?

That's a great example. But, it's not always so clear cut.

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.

I’m thinking a lot about how older applications are often better than new for reasons like this.

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.

What does the author think about the concept of debouncing (common in real world hardware, because electronically signals are not binary).

Busted my Corne-ish Zen yesterday, going back to an Ergodox EZ (until I received 2 new Corne, including one as backup) I can tell that leaving a comfortable and efficient hand based setup is literal pain, both physiological and cognitive. I write and code using Vim (so navigation with keys) and browse with Tridactyl (same principle). It's very rough going back.

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.

One similarly egregious UX issue on the latest Android is that pressing buttons in the dropdown tray doesn't give any feedback until the action is complete. I can press the "turn on WiFi" button and receive zero haptics or visual indication that the phone registered my tap, for over a second, and THEN it will decide "okay! let's shake the phone and change button color now".

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.

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

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.

Hair dryers normally have 2 controls, one to adjust how much air it blows, and another one to adjust how hot the jet is.

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.

A different UX issue I have with these buttons is that the designers seen to have chosen the wrong rotation direction.

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.

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

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.

Even calling it a button is going too far. Buttons are for elevators, doorbells, and payphones. What we have on iPhone and Android is a tactic response imitation system. If there is no physical depression, there is no button.

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

It's Android stop expecting it to make sense. You have to learn some intricacy of some tool so you can forget it and have to learn it again three months later.

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.

I assumed that issues like "tap eight times for a no-op" not working was because of software patents not allowing the developer to do the obvious thing. Is that not the case?

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.

I have a related cybersecurity point.

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

Click me?

Lie you have 4

I'm sure it just my personal preference but I hate animations. Most often they do little other than slow an application down i.e. the code of the application could finish the task almost instantaneously but for the sake of appearance, they make it take longer to finish. I would much prefer no animations in applications. If the animation is there to disguise some actual slow response, just let me wait, give me jarring screen changes. please. Maybe app designers could still include all the animations for "smoothness", "premium look" or "sizzle" but please include an "expert" mode that just turns everything off.

[dead]

[flagged]

[dead]

[dead]

[flagged]

I identify as a button.

[flagged]

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!

This may be true, but it is too random and too insignificant, to my taste.

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.

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.