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.
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.
Debouncing exists for a reason. Sometimes when a button is clicked twice, you want it executed twice, sometimes you don't. Distinguishing which is better in which situation is not trivial.
At the very least, you should consider which is appropriate for which situation, what if, in your UI, for some buttons one is the obvious choice, for others it's the other, but for some it's not so clear, and both behaviours are defensible? Now you've got an inconsistent UI.
a button that debounces requests should be disabled until the action is complete instead, so you can only click it once until it is ready to be clicked again. debouncing button clicks is a design failure (it makes more sense for things like requests that happen during typing, where you don't want to stop the feedback)
Itās really common for people to accidentally click a button twice. Yeah thatās what denouncing is for.
My favorite example of doing it wrong is a log in form: if the login button is clicked twice, the server would reject the login because the first click has already used up the one-time token so the user gets an error page.
But I think the biggest problem is that people either apply denouncing to all buttons in a UI (like turning it on within the framework they are using) or apply denouncing to nothing. So there really isnāt a culture for carefully considering which situations warrant which.
It seems somewhat clear to me. You want it executed twice if and only if the operation isn't idempotent. Can you give an example where you think both behaviors are equally defensible?
> How about when users accidentally click too much, or they believe the first click didnāt register?
I was really confused at their mention of accessibility, because my mind jumped to people with hand tremors who would double press when they intended only one press.
And then, of course, there are the people that double-click every button. To handle that, disabling a submit button in the onclick is very common.
I'm no longer the Apple/Mac/Jobs fan-boy I once was in my earlier days, but I do miss the Apple presentations that felt like they were run by a human being wanting to show off cool stuff.
I couldn't even finish the last Apple presentations as it all feels so stiff, inhuman and run by suits, they all seem like robots scared of diverging from the holy script who will get fired if they display emotions and humanity.
Off-topic perhaps, but got reminded how delightful even the somewhat messy ad-hoc presentations from Jobs were.
The scripted talks in front of fancy backgrounds do make it unpalatable, itās just a fancier version of corporate slideshows. I suppose trillion-dollar companies arenāt as willing to take risks.
That was a common problem in JS-based menu opening and closing, long ago: they were treated as animations and queued. This was sometimes quite ludicrous.
Nowadays, you use transitions instead, which are not queued. But I still very occasionally see things that use queued animations.
Button ā Button. People like to believe they should all be the same, but they really should not be.
On physical keyboards we already have three different kinds: normal buttons, modifier keys (shift, etc) and toggle keys (caps lock).
High stakes rare actions can require special button designs. E.g. on a black magic cinema camera the button that formats the memory card needs to be held for three second while it visually counts down. This gives a small delay during which the user can decide: "Fuck this is the wrong memory card!" and cancle.
The downside is that some imaginary power user that uses the camera only to format a stack of SSDs will get burdened. You have to decide which is more common and make a decision.
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).
Your points are good ones, especially since they emphasize that different people have different expectations of what a "button" is and isn't. Your points individually describe a button with a label, one with a toggle, an actual button, and a progress indicator. All of those things can be "buttons" depending on the user.
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?
Your write imperative code, which issues two commands, both of which can fail independently.
There are plenty of ways to pretend to 'deal with it'.
Firstly it will just pass all tests, so most devs can stop thinking about it right away.
A dev might think you can just catch and log the exception. Doesn't fix it.
You could run the code in prod for a while, see if it goes wrong. It will, at which point the dev will try it again, and it will probably work the second time, so they can stop thinking about it.
There was a big outbox pattern discussion a couple of days ago (split thing 1 into two halves, and do them atomically, leave thing 2 as an exercise for the reader.)
I think the reason you encounter this problem in the real world is that devs just exist in some quantum superposition of "it won't happen" and "I fixed it" and "it can't be fixed".
> A dev might think you can just catch and log the exception. Doesn't fix it.
You've just succinctly made the argument against checked exceptions FWIW (which I agree with you on). Anyone who has used Java in anger (is there any other way?) will be familiar with:
Fault tolerance is general is terrible in most software. One of my biggest bugbears is network latency and transient failures in network requests that would be solved with a simple retry. But no, there's an incredibly lazy "Request failed" dialog to the user. That's the equivalent of the "log and silently swallow" pattern above. It can get a lot worse than that too. I have an app on my phone that will log me out and force me into a 2FA cycle if it hits a network timeout. Like.... WHYW?!?!?! Anyway, I digress...
This is largely a sotware issue. Control systems are built to handle these kinds of things. A traffic light can't accidentally show green in two directions. It's literally wired for that to be impossible because it's simply too important for it to not be possible. You constantly have to deal with faulty sensors so you have systems that will seek a consensus from 3+ sensors and, if that fails, it'll fail until you fix it.
But in software the standards just seem to be much lower even though it can be critical, even lethal eg [1]. Network interfaces should be fuzzed. Every IO operation should assume it can fail and be tested for when it does. Every IO operation should produce unexpected output. And it's simply cost-cutting and a lack of regulation that allows this sloppiness to persist. There should certainly be strict liability for any companies that allow this to happen.
This is really common because of two design features that most UI frameworks share:
- The code that changes the color of the button is an internal part of the "button" component, so that people don't have to individually implement it on every button. But this means that it's kind of disconnected from the code that actually performs the action. If the "on click" handler has some last-ditch check that aborts the action, like the "don't rotate the image if it's in the middle of the rotate animation" check from the article, often there's no way for it to tell the button to cancel the color change. (And conversely sometimes the "on click" handler can fire even if the color change animation doesn't play correctly.)
- Buttons usually change color when you press down the mouse button, but only perform the action when you release the mouse button. Sometimes this is used to intentionally give you a chance to cancel the action at the very last minute by dragging your mouse off the button while it's still held down (or, on mobile, to e.g. reinterpret your interaction as scrolling instead of clicking), other times it just creates more opportunities for something to happen that prevents the action from working after the color change has already happened.
> there's no way for it to tell the button to cancel the color change
No, but what should happen in cases like that is that the on-click handler disables the button while it is unresponsive. This will communicate the fact that the button is unresponsive visually to the user and also inhibit the button-was-pressed feedback.
> Sometimes this is used to intentionally give you a chance to cancel the action
EDIT: sometimes UI elements with mouse-held interaction allow you to use the escape key to cancel an in-progress interaction (ESC: abort, mouse-up: commit) however the reply button on this page doesn't work that way so I have to edit this message to add this. That escape-key behavior should be universal I think.
I notice this pretty consistently with elevators: If you press the button for a short amount of time, it visibly lights up while pressed but doesn't actually register the button-press.
The color change of the button shows you succeeded in pushing it. If you don't do this instantly most people are conditioned to try again. This is especially valuable for people with reduced motor control.
It is completely independent of whether that push is a useful input given the current state of the software. Obviously when well written software knows it can't accept the input it should have disabled the button, and even moderately well written software needs to provide a near instant feedback that the action is processing or has been cancelled.
I suppose a lack of testing and an assumption that the action will fail so rarely that itās not worth accounting for? But yes, such patterns make it hard to trust and efficiently use an interface.
I've only worked for one company that actually did proper QA testing. It's expensive and time consuming and often the main functionality is okay, so many just skips QA altogether.
It is probably daily that I encounter products and procedures where I can see that a given scenario is kind of a an edge case, but not an unforeseeable one. Given the scale of many things, edge cases happen pretty frequently and with ever more ridged organisations, lack of customer service, human interaction and a quest for ever more cost savings, hitting an edge case can be everything from frustrating to catastrophic for a person.
Generally I think we, as in humans, need to slow down.
Not handling rare cases is the root of a lot of bad software. āOh, this bug will only affect 1% of users. Donāt bother fixing it: we have features to cram.ā
Bad programming. People who have experience with embedded programming knows that reading out a button usually means denouncing. At the speed a microcontroller can read out a button it will change it's state multiple times per press because of contact bounce. Meaning when a user presses a button the program sees off, on, off, off, on, on, off, on, on, on, on, on, on, etc.
Now if you just naively read out the current state of the button and do something with it elsewhere in the program looping may be off or on randomly.
It is not hard to imagine if there is some other logic (or e.g. a rate limit) on the 30 seconds and on the beep that these would see different slices in time of the button. Congrats you built a button-debounce based RNG.
Physical buttons can be surprisingly complex if you don't rely on someone else's driver. The correct solution is to debounce the button, that can be done either in hardware (too expensive, so rarely done) or in softeare, by e.g. averaging the last 50 reads and wait till the majority is either off or on.
This should be common knowledge for embedded programmers, but every noe and then you will see someone who has never heard of it.
>averaging the last 50 reads and wait till the majority is either off or on.
This is a bad way to do it because it adds avoidable latency. A moving average is a low-pass filter. The switch bounce is better handled by hysteresis. Change state as soon as you see an edge, then ignore further edges until a timer expires, e.g. 5 ms, which should be enough for the bouncing to settle. A 5 ms timeout limits your repetition rate to 100 presses per second, which is beyond human capabilities.
You might want a tiny bit of hardware low-pass filtering too, for EMI resistance, but that's with microsecond-scale time constant, not milliseconds.
Checking the button state a bunch of times and computing an average wastes a ton of clock cycles that you could be doing anything else (like updating a display, polling sensors, etc).
The standard way to debounce is to attach an timer to the button. When you press the button, an ISR runs that temporarily disable the timer from triggering again and starts the timer for a specific period (say 20ms). The processor is free to do whatever it wants for the next 20ms. When that timer expires, another routine checks to see if the button is still being held, sets the button's state accordingly, then re-enables the button Timer so it can be triggered again.
Averaging loops are much better for analog inputs where you may have noise that throws off the reading. You only care about a button being on or off, it doesn't matter if it's been mostly on for that period only that it's still on.
When you get into extremely fast digital inputs that need to be reacted to sooner than the debounce wait period, that's when you need hardware debouncing.
Another one I see is low end devices have a volume knob that instead of being a potentiometer are a rotary dial encoder so you end up usually only being able to adjust the volume as fast as it's sampled, which is slower than you want for example in traffic turning the radio down to hear stuff
> to mask loading times and ease from one state into the other
I'd expand on this: used well, they show the user than a state change is happening directly because of a particular action of theirs, and hint at how they might reverse or modify it.
In fact I'd disagree with masking. If something appeared instantly with no hint as to why, that is a distinct anti-pattern on a touch screen.
I don't want my image editor to feel like something in a creative manner though.
I want it to rotate an image by 90Ā° when I tap the button that does that.
See, this is exactly my point when I say that animations are no end in themselves.
They serve a supporting role to better get the actual job done.
The actual job is not "feel" it is "do". For vibes, there are movies, Art, and AI hallucinations.
Of course, "feel" can greatly enhance the "do", but only if it takes the back seat, which is exactly what I just said.
__
The age-old debate "form follows function" vs "form over function", essentially.
One of them is correct tho, because in the real non-ZIRP world, correctness is defined as "achieves a tangible goal".
Which is not to say that stuff optimizing for other goals would be "incorrect" or "worthless", but it exists in a different category from "software". More like "software-adjacent Art".
The distinction being made based on "what is the primary goal we want to achieve here"
____
Related:
Also caused by ZIRP but differently, we have that problem that software trying to invoke feelings usually does so because it wants to sell you something or has any other style of goal that might not be aligned with yours.
So that adds yet another layer.
Pure utility cannot scam people into stuff they actually didn't want to do.
I have disabled all animations on my Android, and it feels so much nice. I particularly HATE that one animation where the whole screen stretches if you try to overscroll.
Dude that animation sucks so much I could not believe that there was no way of disabling that without disabling _all_ animations.
The fact that it makes content move in a way that is illegal breaks my mind.
You try to check "is this the end" and it all starts moving.
What the hell. Why.
I kinda forgot just how much I hate this animation. Thanks for the reminder.
Why, google.
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.
iOS has an accessibility option called "Ignore Repeats", which seems like a better approach because it's system-wide. So people who need that kind of accommodation can have it in places like the on-screen keyboard too, without needing everyone else to slow down their typing.
That's good. I wonder if it should be opt-in instead of opt-out. Disabled people are arguably less able to find random configuration options than non-disabled counterparts. I get a bit bothered with how undiscoverable these options are. But power-users by their nature don't mind going to the extra mile to get perf out of their experiences.
I totally agree, even not going as far as a Parkinson case, if you already so old and not too old persons use phones and touch screens, you will see that very often it is complicated for them to click on the small button at the right place and to have the feeling that "they have clicked".
So, for me, on the argument of about accessibility, the Nothing Phone behavior will work a lot better I think. In their mind they don't count and click 6 times to put the image in a specific position. In addition with considering that it would not make much sense to click 8 times in advance to turn back in the exact position where you are.
The mindset in their case is more: click and wait, compare if it is the position you want and do it again. The other sensitive button that will bufer would probably trigger overshooting, going too far, then too back, etc... similarly to when you have issue scrolling in a list to the right spot.
The case of the iphone would be better only for someone like a younger person, tech nerd, that want things to go fast without having to wait. Same thing for computer keyboards where I could type multiple letters in advance before the first one even show up on the screen with the lag.
Around 2011, my grandfather with Parkinsonās and deteriorating eyesight received an iPad from family. They didnāt use it for much, mostly video calls and reading the Bible, with the text steadily getting larger and larger (up to letters being more than 5cm tall towards the end). It was funny just how good it was if an app only supported iPhone and not iPad, because then the iPad would scale it up to double physical size.
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.
I wish software apps had "tape-out rules" the way that computer chips do. Basically, when you design a computer chip, a program reviews the design and compares it against something like 300 pages of rules with stuff like "wires of X metal and Y metal can't be within Z distance of each other".
We could make something similar for UX. Just a bunch of design pattern constraints that throw flags if you try to ship something with well established UX warts.
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.
It's interesting that we're so used to the GUI buttons having that specific behavior of only triggering when releasing, even if you exit and enter the button area while holding the mouse button down, etc.
IRL 99%+ of buttons work by just doing the thing as soon as you press them. But a button that works like that in a GUI would feel wrong.
> But a button that works like that in a GUI would feel wrong.
No, it doesn't. It feels way more responsive.
My pet peeve is "stopwatch apps" which trigger on release instead of on press. When timing something where fractions of a second matter, most people won't realize that it triggers on release and tap down when they want to start / stop, adding some arbitrary delay until they actually release the button.
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.
When on Speaker/hands-free mode, it just closes screen. They assume you wouldn't press lock button while against your ear, because it closes the screen automatically. The problem is that there's some bugs that keep the screen open sometimes, or you may use it in a quiet room as if it were on hands-free.
As a user, I much prefer a blocking UI thread to one that lets me spam clicks on the "rotate left" and "flip along vertical axis" buttons and then makes me wonder why the resulting image is not the flipped verstion of what I saw the moment when I clicked "flip".
However, I do like being able to abort my operations, and a blocking thread does not let me do that.
It might be quite a hard problem to determine which buttons should be disabled during which operations. One tricky candidate is the "safe" button. Should I be able to click it when the visual feedback I'm getting does not yet match the internal state of the application (which is what will be saved)? Should I be able to start further tasks when the save is still in progress? (If so, what if the save fails? Will I be able to roll back to the state before the attempted save and try again?)
Its a perfect illustration of the tradeoffs between synchronous and asynchronous logic. Synchronous logic allows for maximal consistency at the cost of wasting time. Asynchronous logic allows you to use time efficiently, but requires you to track all the different states you can be in simultaneously.
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.
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?
It shouldn't buffer them like the author describes. It should execute the buttonās function immediately when pressed. This might mean to cancel the current animation and jump ahead, or it might mean to speed it up by the appropriate factor so it takes the same amount of time as it does for one button press. Either way is massively preferable to a button that swallows my input.
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.
That's a different bad UX pattern. If a button has already rendered in a certain location, a new button shouldn't replace it without first giving the user ample warning that a material change is about to happen.
Isn't that a different issue from what the blog post described and easily solved by holding everyone who allows their UX elements to get pushed around, for whatever reason, to the fire?
If you tap for directions and then tap to change the mode of transportation as it's loading the routes then it thinks you've picked the first route because it bumps the transport mode panel up in order to show the first route in the list.
Very annoying as they could just account for the height of the first route from the start.
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 think iOS has lots of refinement and polish, but still lots of ugly bugs and crappy UI. The others have the same crappy UI, but with no refinement and polish at all anywhere.
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.
It's not that iphone keeps that 4; it's that iphone pretty quickly starts accepting the next round of input after 1123 and then you type 4.
Perhaps a longer pause will prevent you from typing that 4 but that also means other people who mistype their passcode have to wait longer to retry. It's a tradeoff. I suspect there are more people who type the wrong passcode of the correct length than the incorrect length.
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.
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.
That's a good example of bad UX, and, in a way, counter to the article.
It sounds like Android needs a middle state indicator. When your action is in a pending state, the state indicator should not be the same as the previous state. A common pattern is to show a pending animation.
While this animation is running, what should happen if the user presses the button?
I've yet to update to Android 17, but I ended up disabling haptics on 16 because the annoying pop sound feels like a gimmick compared to what haptic feedback used to be.
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.
My rule of thumb is that animations need a purpose, otherwise you are just showing off and it gets tedious. This animation carries more purpose than most, conceptually you might understand which orientation will be next but it takes your brain a second to validate, and it is much simpler if you can see the path that it took.
Eliminating these animations is indeed a massive win.
Overuse of animations is a terrible thing that has made iOS far worse over the years. I long for the days of yore, when the loading screenshot had a chance of being accurate.
These days, when loading something like the health app I get a series of three different screens, rather than just landing at the destination it knew o wanted to start at. It is idiocy of the highest order. Why show some series of random screen transitions while starting the app? Somebody who has no clue about UX programmed that piece of crap, and then an entire team put up with this behavior. I dearsay that if this shipped under jobs there would be a director level firing to stop it.
Same BS happens with Apple Maps. If you launch the app and it remembers that an hour, day, or two weeks ago you had your phone in a particular orientation forever ago, it slowly rotates the view pane over 1000-2000ms from you ancient view pane as if you've been waiting patiently over two weeks so that Maps doesn't suddenly disrupt your view...
Animation can be helpful but at some point a half-wit VP shoved it into everything Ruth disastrous results and Apple is still recovering. Liquid Glass is a similar disaster of incompetence being promoted far beyond capability.
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.
Possibly a consumer air dryer problem, something-something safety. Check professional ones like Parlux, the one I checked has 2 dials: airflow and temperature. Turns on by air dial. They are also conveniently under the thumb so you can adjust without looking.
Yes it's safety related. Turning the heater on while the airflow if off is a sure way to start a fire.
It could be fixed with a relay or a solid state switch on the heater, or with a multipolar toggle on the airspeed. But that's several cents more expensive than making it turn on at the heater switch.
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.
Even in unstable or high latency I like the buffering. Iām thinking of a remote shell, where you want to type a command blindly, and see it appear seconds later, because keys got buffered in the Internet pipes. Without buffering it would feel awful, having to wait a full roundtrip per keystroke
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.
A press of each round button rotates the typing ball accordingly, pressing the space prints the chosen letter and resets the ball to the neutral state. This whole thing should probably be electric lest you'd have to press the space bar by smashing it with both fists.
Now remove the spacebar, combine the two buttons into a single one for "tone" and adapt it to morse code. All the buttons still do only one thing and now there's only one button!
And, you don't have to worry about what to do in the case that someone hits the "rotate ball" button while it's still rotating.
Yeah, sometimes, when I am sitting before my computer and typing comments on the Internet, I have a thought: "Is my computer turned on?" With a quick glance under my table I can reassure myself that it is indeed on and continue using it. No idea what I'd do without that small blue LED.
The pilot lights are slightly more useful in those stupid cross-wired double switches that for some weird reason implement a sort of XOR (or sometimes XNOR because why not) gate for controlling a single light: if it's on, then the bulb is depowered and you can safely change it without turning off the entire power rail. But then one day the pilot light itself burns out...
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.
That's a great example of bugs in overcomplexity. The requirements were relatively simple, but they went for a full-on multitasking OS with all the complexity that entails.
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.
Using AOSP-based Android roms, I haven't noticed any big changes in years. In current "android 16" and my old "android 10" device one couldn't really tell a difference. Very simple UX, no bloatware apps, no hidden drawers coming out from sides.
I've tried the vendor ones by Samsung, OnePlus etc with fresh devices and this Android experience really is awful.
I wish there was more love for more vanilla forms of Android. I would trade more simplicity out of the box and regular software updates over the current situation.
Personally I'm blown away by Motorola options in the budget range. For raw value alone there offerings are hard to beat.
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 don't have any specifics, but based on experience, it feels like software giants like to patent what a lot of people would consider obvious wins (such as interruptible animations) if no other company happens to be doing it, and it felt like this would be something where that could be the case.
That said, I can't seem to find any evidence of this particular thing being patented to support my case, so it's probable that I'm wrong.
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 think this is a distinction without a difference. Imagine an array of buttons. What do they do? The label is intrinsic to the button. I understand this is a perspective. But, taking this to another level, perhaps an absurd one,the button only sends messages and ideally reacts to show it's been activated.
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.
Then I definitely need to get some caffeine I guess *yawns*
> 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.
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.
Some years ago, I attended an informal demo of some application we built. The engineer who had worked on the UI was showing an animation of the initial splash screen. It was only 5 seconds or so but I asked him whether there was an option to disable it. He said there wasn't. I then asked if he didn't think that a user, running this many times, was going to get very tired of seeing it run every time and want to just show the home window immediately on start. I said I knew I would. I told him that regardless of how "cool" it looked, when you see the same thing a few times, it can become annoying leaving the user pissed off because its out of their control. I don't know what happened after that. Since I didn't have any authority to request changes, I was probably ignored.
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!
Similarly, why don't photos get auto-straightened, maybe with an option to revert to original? I spend too much time aligning the horizon properly on snapshots that I took while cycling. The phone even has the data from the rotation sensor, so this should be fairly easy to implement.
Not prevent, just not provide very responsive feedback, right?
I don't know, I understand the principle, but I don't see how you can determine the value of a principle outside of a specific context.
Even for accessibility, we can't target every context in the name of being accessible. We still have to pick which contexts of inaccessibility we'll need to support with more attention.
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.
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.
Debouncing exists for a reason. Sometimes when a button is clicked twice, you want it executed twice, sometimes you don't. Distinguishing which is better in which situation is not trivial.
At the very least, you should consider which is appropriate for which situation, what if, in your UI, for some buttons one is the obvious choice, for others it's the other, but for some it's not so clear, and both behaviours are defensible? Now you've got an inconsistent UI.
I have no good solution for this.
a button that debounces requests should be disabled until the action is complete instead, so you can only click it once until it is ready to be clicked again. debouncing button clicks is a design failure (it makes more sense for things like requests that happen during typing, where you don't want to stop the feedback)
Itās really common for people to accidentally click a button twice. Yeah thatās what denouncing is for.
My favorite example of doing it wrong is a log in form: if the login button is clicked twice, the server would reject the login because the first click has already used up the one-time token so the user gets an error page.
But I think the biggest problem is that people either apply denouncing to all buttons in a UI (like turning it on within the framework they are using) or apply denouncing to nothing. So there really isnāt a culture for carefully considering which situations warrant which.
It seems somewhat clear to me. You want it executed twice if and only if the operation isn't idempotent. Can you give an example where you think both behaviors are equally defensible?
> How about when users accidentally click too much, or they believe the first click didnāt register?
I was really confused at their mention of accessibility, because my mind jumped to people with hand tremors who would double press when they intended only one press.
And then, of course, there are the people that double-click every button. To handle that, disabling a submit button in the onclick is very common.
I'm no longer the Apple/Mac/Jobs fan-boy I once was in my earlier days, but I do miss the Apple presentations that felt like they were run by a human being wanting to show off cool stuff.
I couldn't even finish the last Apple presentations as it all feels so stiff, inhuman and run by suits, they all seem like robots scared of diverging from the holy script who will get fired if they display emotions and humanity.
Off-topic perhaps, but got reminded how delightful even the somewhat messy ad-hoc presentations from Jobs were.
I agree 100%. I stopped watching after iPhone 15 event or maybe M2.
Absolutely everything seems scripted including hand movements, shifting of postures, smiles..the whole works.
Now I just wait for the press release and thatās that.
The scripted talks in front of fancy backgrounds do make it unpalatable, itās just a fancier version of corporate slideshows. I suppose trillion-dollar companies arenāt as willing to take risks.
Apple keeps solving the same old problems. Why are we still talking about how well their buttons behave?
"How about"? These situations might exist, but this clearly isn't one. Two reasons:
1. "The Nothing Phone button gives you a tap confirmation via both haptics and sound, and then ignores the tap [ā¦]"
2. There is a really good reason to tap this button 3 times in a row.
That was a common problem in JS-based menu opening and closing, long ago: they were treated as animations and queued. This was sometimes quite ludicrous.
Nowadays, you use transitions instead, which are not queued. But I still very occasionally see things that use queued animations.
Button ā Button. People like to believe they should all be the same, but they really should not be.
On physical keyboards we already have three different kinds: normal buttons, modifier keys (shift, etc) and toggle keys (caps lock).
High stakes rare actions can require special button designs. E.g. on a black magic cinema camera the button that formats the memory card needs to be held for three second while it visually counts down. This gives a small delay during which the user can decide: "Fuck this is the wrong memory card!" and cancle.
The downside is that some imaginary power user that uses the camera only to format a stack of SSDs will get burdened. You have to decide which is more common and make a decision.
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).
>But I also hate the "you had one job" meme and want to argue against its mindless usage
the "you had one job" meme could pretty much always be followed up by "because i refused to consider the actual complexity of your job"
Your points are good ones, especially since they emphasize that different people have different expectations of what a "button" is and isn't. Your points individually describe a button with a label, one with a toggle, an actual button, and a progress indicator. All of those things can be "buttons" depending on the user.
> what about debouncing
activate button function on touch release instead of touch down?
anecdotally that feels so much worse and sluggish
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?
I call it the "doing two things" problem.
Your write imperative code, which issues two commands, both of which can fail independently.
There are plenty of ways to pretend to 'deal with it'.
Firstly it will just pass all tests, so most devs can stop thinking about it right away.
A dev might think you can just catch and log the exception. Doesn't fix it.
You could run the code in prod for a while, see if it goes wrong. It will, at which point the dev will try it again, and it will probably work the second time, so they can stop thinking about it.
There was a big outbox pattern discussion a couple of days ago (split thing 1 into two halves, and do them atomically, leave thing 2 as an exercise for the reader.)
I think the reason you encounter this problem in the real world is that devs just exist in some quantum superposition of "it won't happen" and "I fixed it" and "it can't be fixed".
> A dev might think you can just catch and log the exception. Doesn't fix it.
You've just succinctly made the argument against checked exceptions FWIW (which I agree with you on). Anyone who has used Java in anger (is there any other way?) will be familiar with:
Fault tolerance is general is terrible in most software. One of my biggest bugbears is network latency and transient failures in network requests that would be solved with a simple retry. But no, there's an incredibly lazy "Request failed" dialog to the user. That's the equivalent of the "log and silently swallow" pattern above. It can get a lot worse than that too. I have an app on my phone that will log me out and force me into a 2FA cycle if it hits a network timeout. Like.... WHYW?!?!?! Anyway, I digress...This is largely a sotware issue. Control systems are built to handle these kinds of things. A traffic light can't accidentally show green in two directions. It's literally wired for that to be impossible because it's simply too important for it to not be possible. You constantly have to deal with faulty sensors so you have systems that will seek a consensus from 3+ sensors and, if that fails, it'll fail until you fix it.
But in software the standards just seem to be much lower even though it can be critical, even lethal eg [1]. Network interfaces should be fuzzed. Every IO operation should assume it can fail and be tested for when it does. Every IO operation should produce unexpected output. And it's simply cost-cutting and a lack of regulation that allows this sloppiness to persist. There should certainly be strict liability for any companies that allow this to happen.
[1]: https://ethicsunwrapped.utexas.edu/case-study/therac-25
Why can the two things even fail at all?
> Why? How, even, have they implemented this?
This is really common because of two design features that most UI frameworks share:
- The code that changes the color of the button is an internal part of the "button" component, so that people don't have to individually implement it on every button. But this means that it's kind of disconnected from the code that actually performs the action. If the "on click" handler has some last-ditch check that aborts the action, like the "don't rotate the image if it's in the middle of the rotate animation" check from the article, often there's no way for it to tell the button to cancel the color change. (And conversely sometimes the "on click" handler can fire even if the color change animation doesn't play correctly.)
- Buttons usually change color when you press down the mouse button, but only perform the action when you release the mouse button. Sometimes this is used to intentionally give you a chance to cancel the action at the very last minute by dragging your mouse off the button while it's still held down (or, on mobile, to e.g. reinterpret your interaction as scrolling instead of clicking), other times it just creates more opportunities for something to happen that prevents the action from working after the color change has already happened.
> there's no way for it to tell the button to cancel the color change
No, but what should happen in cases like that is that the on-click handler disables the button while it is unresponsive. This will communicate the fact that the button is unresponsive visually to the user and also inhibit the button-was-pressed feedback.
> Sometimes this is used to intentionally give you a chance to cancel the action
EDIT: sometimes UI elements with mouse-held interaction allow you to use the escape key to cancel an in-progress interaction (ESC: abort, mouse-up: commit) however the reply button on this page doesn't work that way so I have to edit this message to add this. That escape-key behavior should be universal I think.
I notice this pretty consistently with elevators: If you press the button for a short amount of time, it visibly lights up while pressed but doesn't actually register the button-press.
I have long presumed that sort of thing to be deliberate, avoiding activation on accidental bump.
The color change of the button shows you succeeded in pushing it. If you don't do this instantly most people are conditioned to try again. This is especially valuable for people with reduced motor control. It is completely independent of whether that push is a useful input given the current state of the software. Obviously when well written software knows it can't accept the input it should have disabled the button, and even moderately well written software needs to provide a near instant feedback that the action is processing or has been cancelled.
I suppose a lack of testing and an assumption that the action will fail so rarely that itās not worth accounting for? But yes, such patterns make it hard to trust and efficiently use an interface.
I've only worked for one company that actually did proper QA testing. It's expensive and time consuming and often the main functionality is okay, so many just skips QA altogether.
It is probably daily that I encounter products and procedures where I can see that a given scenario is kind of a an edge case, but not an unforeseeable one. Given the scale of many things, edge cases happen pretty frequently and with ever more ridged organisations, lack of customer service, human interaction and a quest for ever more cost savings, hitting an edge case can be everything from frustrating to catastrophic for a person.
Generally I think we, as in humans, need to slow down.
Not handling rare cases is the root of a lot of bad software. āOh, this bug will only affect 1% of users. Donāt bother fixing it: we have features to cram.ā
This is sometimes done intentionally to hide latency and make a UI feel faster - I certainly donāt like it though.
Bad programming. People who have experience with embedded programming knows that reading out a button usually means denouncing. At the speed a microcontroller can read out a button it will change it's state multiple times per press because of contact bounce. Meaning when a user presses a button the program sees off, on, off, off, on, on, off, on, on, on, on, on, on, etc.
Now if you just naively read out the current state of the button and do something with it elsewhere in the program looping may be off or on randomly.
It is not hard to imagine if there is some other logic (or e.g. a rate limit) on the 30 seconds and on the beep that these would see different slices in time of the button. Congrats you built a button-debounce based RNG.
Physical buttons can be surprisingly complex if you don't rely on someone else's driver. The correct solution is to debounce the button, that can be done either in hardware (too expensive, so rarely done) or in softeare, by e.g. averaging the last 50 reads and wait till the majority is either off or on.
This should be common knowledge for embedded programmers, but every noe and then you will see someone who has never heard of it.
>averaging the last 50 reads and wait till the majority is either off or on.
This is a bad way to do it because it adds avoidable latency. A moving average is a low-pass filter. The switch bounce is better handled by hysteresis. Change state as soon as you see an edge, then ignore further edges until a timer expires, e.g. 5 ms, which should be enough for the bouncing to settle. A 5 ms timeout limits your repetition rate to 100 presses per second, which is beyond human capabilities.
You might want a tiny bit of hardware low-pass filtering too, for EMI resistance, but that's with microsecond-scale time constant, not milliseconds.
Checking the button state a bunch of times and computing an average wastes a ton of clock cycles that you could be doing anything else (like updating a display, polling sensors, etc).
The standard way to debounce is to attach an timer to the button. When you press the button, an ISR runs that temporarily disable the timer from triggering again and starts the timer for a specific period (say 20ms). The processor is free to do whatever it wants for the next 20ms. When that timer expires, another routine checks to see if the button is still being held, sets the button's state accordingly, then re-enables the button Timer so it can be triggered again.
Averaging loops are much better for analog inputs where you may have noise that throws off the reading. You only care about a button being on or off, it doesn't matter if it's been mostly on for that period only that it's still on.
When you get into extremely fast digital inputs that need to be reacted to sooner than the debounce wait period, that's when you need hardware debouncing.
> People who have experience with embedded programming knows that reading out a button usually means denouncing
I know you mean "debouncing" but I love the autocorrect. Like the button is some almighty authority that Denounces noisy signals.
Ahh, the stochastic behavior of networked devices!
Another one I see is low end devices have a volume knob that instead of being a potentiometer are a rotary dial encoder so you end up usually only being able to adjust the volume as fast as it's sampled, which is slower than you want for example in traffic turning the radio down to hear stuff
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.
> to mask loading times and ease from one state into the other
I'd expand on this: used well, they show the user than a state change is happening directly because of a particular action of theirs, and hint at how they might reverse or modify it.
In fact I'd disagree with masking. If something appeared instantly with no hint as to why, that is a distinct anti-pattern on a touch screen.
They arenāt purely for that, they also contribute to how an application feels to use in a creative manner.
I don't want my image editor to feel like something in a creative manner though.
I want it to rotate an image by 90Ā° when I tap the button that does that.
See, this is exactly my point when I say that animations are no end in themselves. They serve a supporting role to better get the actual job done.
The actual job is not "feel" it is "do". For vibes, there are movies, Art, and AI hallucinations.
Of course, "feel" can greatly enhance the "do", but only if it takes the back seat, which is exactly what I just said.
__
The age-old debate "form follows function" vs "form over function", essentially.
One of them is correct tho, because in the real non-ZIRP world, correctness is defined as "achieves a tangible goal".
Which is not to say that stuff optimizing for other goals would be "incorrect" or "worthless", but it exists in a different category from "software". More like "software-adjacent Art".
The distinction being made based on "what is the primary goal we want to achieve here"
____
Related:
Also caused by ZIRP but differently, we have that problem that software trying to invoke feelings usually does so because it wants to sell you something or has any other style of goal that might not be aligned with yours.
So that adds yet another layer.
Pure utility cannot scam people into stuff they actually didn't want to do.
I find animations to almost always be gratuitous. I disable them in all cases where the app or system gives me that ability.
I have disabled all animations on my Android, and it feels so much nice. I particularly HATE that one animation where the whole screen stretches if you try to overscroll.
Dude that animation sucks so much I could not believe that there was no way of disabling that without disabling _all_ animations.
The fact that it makes content move in a way that is illegal breaks my mind. You try to check "is this the end" and it all starts moving. What the hell. Why.
I kinda forgot just how much I hate this animation. Thanks for the reminder. Why, google.
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.
iOS has an accessibility option called "Ignore Repeats", which seems like a better approach because it's system-wide. So people who need that kind of accommodation can have it in places like the on-screen keyboard too, without needing everyone else to slow down their typing.
That's good. I wonder if it should be opt-in instead of opt-out. Disabled people are arguably less able to find random configuration options than non-disabled counterparts. I get a bit bothered with how undiscoverable these options are. But power-users by their nature don't mind going to the extra mile to get perf out of their experiences.
I don't think this is something every UI widget ever should have to think about.
It could probably be done as a global device setting - e.g. ignore taps within 100ms if they're within 50px of each other or whatever.
I totally agree, even not going as far as a Parkinson case, if you already so old and not too old persons use phones and touch screens, you will see that very often it is complicated for them to click on the small button at the right place and to have the feeling that "they have clicked".
So, for me, on the argument of about accessibility, the Nothing Phone behavior will work a lot better I think. In their mind they don't count and click 6 times to put the image in a specific position. In addition with considering that it would not make much sense to click 8 times in advance to turn back in the exact position where you are.
The mindset in their case is more: click and wait, compare if it is the position you want and do it again. The other sensitive button that will bufer would probably trigger overshooting, going too far, then too back, etc... similarly to when you have issue scrolling in a list to the right spot.
The case of the iphone would be better only for someone like a younger person, tech nerd, that want things to go fast without having to wait. Same thing for computer keyboards where I could type multiple letters in advance before the first one even show up on the screen with the lag.
Around 2011, my grandfather with Parkinsonās and deteriorating eyesight received an iPad from family. They didnāt use it for much, mostly video calls and reading the Bible, with the text steadily getting larger and larger (up to letters being more than 5cm tall towards the end). It was funny just how good it was if an app only supported iPhone and not iPad, because then the iPad would scale it up to double physical size.
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.
I wish software apps had "tape-out rules" the way that computer chips do. Basically, when you design a computer chip, a program reviews the design and compares it against something like 300 pages of rules with stuff like "wires of X metal and Y metal can't be within Z distance of each other".
We could make something similar for UX. Just a bunch of design pattern constraints that throw flags if you try to ship something with well established UX warts.
Thereās effectively no universal list of UX warts people agree with.
The Flat UX fad was objectively terrible on just about every metric I was taught, but people were actively pushing for such designs.
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.
It's interesting that we're so used to the GUI buttons having that specific behavior of only triggering when releasing, even if you exit and enter the button area while holding the mouse button down, etc.
IRL 99%+ of buttons work by just doing the thing as soon as you press them. But a button that works like that in a GUI would feel wrong.
> But a button that works like that in a GUI would feel wrong.
No, it doesn't. It feels way more responsive.
My pet peeve is "stopwatch apps" which trigger on release instead of on press. When timing something where fractions of a second matter, most people won't realize that it triggers on release and tap down when they want to start / stop, adding some arbitrary delay until they actually release the button.
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.
When on Speaker/hands-free mode, it just closes screen. They assume you wouldn't press lock button while against your ear, because it closes the screen automatically. The problem is that there's some bugs that keep the screen open sometimes, or you may use it in a quiet room as if it were on hands-free.
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?
As a user, I much prefer a blocking UI thread to one that lets me spam clicks on the "rotate left" and "flip along vertical axis" buttons and then makes me wonder why the resulting image is not the flipped verstion of what I saw the moment when I clicked "flip". However, I do like being able to abort my operations, and a blocking thread does not let me do that.
It might be quite a hard problem to determine which buttons should be disabled during which operations. One tricky candidate is the "safe" button. Should I be able to click it when the visual feedback I'm getting does not yet match the internal state of the application (which is what will be saved)? Should I be able to start further tasks when the save is still in progress? (If so, what if the save fails? Will I be able to roll back to the state before the attempted save and try again?)
Its a perfect illustration of the tradeoffs between synchronous and asynchronous logic. Synchronous logic allows for maximal consistency at the cost of wasting time. Asynchronous logic allows you to use time efficiently, but requires you to track all the different states you can be in simultaneously.
The real article getting to the point the author is trying to make is this one https://aresluna.org/show-your-hands-honor/
Ok, we'll put that link in the toptext as well. Thanks!
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.
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.
Thatās good life advice.
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-...
I am puzzled (and irritated) why there is ārotate leftā without ārotate rightā. Does any of you know why?
Two wrongs don't make a right but three lefts do, and that seems like a reasonable tradeoff to reduce visual clutter
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?
It shouldn't buffer them like the author describes. It should execute the buttonās function immediately when pressed. This might mean to cancel the current animation and jump ahead, or it might mean to speed it up by the appropriate factor so it takes the same amount of time as it does for one button press. Either way is massively preferable to a button that swallows my input.
One way to deal with it could be āguaranteed interruptā action (something like sigkill, just for UI action queue).
Other way could be to actually visually indicate action queue depth.
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.
That's a different bad UX pattern. If a button has already rendered in a certain location, a new button shouldn't replace it without first giving the user ample warning that a material change is about to happen.
Isn't that a different issue from what the blog post described and easily solved by holding everyone who allows their UX elements to get pushed around, for whatever reason, to the fire?
Yeah, that is an issue in Apple Maps.
If you tap for directions and then tap to change the mode of transportation as it's loading the routes then it thinks you've picked the first route because it bumps the transport mode panel up in order to show the first route in the list.
Very annoying as they could just account for the height of the first route from the start.
Then don't give UI and haltic feedback.
Sorry how is this relevant to the example?
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.
This still exists on modern Androids (thanks God!)
Even better: they moved it from developer options to accessibility options, which means that they treat it as a normal use case now
What is bad is that it still disables the animations for progress bars (the only place where the animation makes sense)
Tangentially related, games added various menu transition animations on purpose, to disable user input while loading resources (from hdd or network).
Idea being that for user it is less frustrating to wait for animation to end, than to see some hourglass/waiting indication.
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 have only iphone, but from my experience, apple ui quality is just a huge myth nothing to do with reality.
On average it is has same amount of crappy UI experience, just in different places.
I think iOS has lots of refinement and polish, but still lots of ugly bugs and crappy UI. The others have the same crappy UI, but with no refinement and polish at all anywhere.
How can you compare if you have only iPhone?
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.
It's not that iphone keeps that 4; it's that iphone pretty quickly starts accepting the next round of input after 1123 and then you type 4.
Perhaps a longer pause will prevent you from typing that 4 but that also means other people who mistype their passcode have to wait longer to retry. It's a tradeoff. I suspect there are more people who type the wrong passcode of the correct length than the incorrect length.
In summary:
Record actions until interrupt.
Animation should not be considered interrupt.
An Error message should be treated as interrupt.
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).
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.
That's a good example of bad UX, and, in a way, counter to the article.
It sounds like Android needs a middle state indicator. When your action is in a pending state, the state indicator should not be the same as the previous state. A common pattern is to show a pending animation.
While this animation is running, what should happen if the user presses the button?
I've yet to update to Android 17, but I ended up disabling haptics on 16 because the annoying pop sound feels like a gimmick compared to what haptic feedback used to be.
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.
In the Google photos app (Pixel 10) there is no animation, the rotation just happens immediately and there's no button press to buffer.
My rule of thumb is that animations need a purpose, otherwise you are just showing off and it gets tedious. This animation carries more purpose than most, conceptually you might understand which orientation will be next but it takes your brain a second to validate, and it is much simpler if you can see the path that it took.
Eliminating these animations is indeed a massive win.
Overuse of animations is a terrible thing that has made iOS far worse over the years. I long for the days of yore, when the loading screenshot had a chance of being accurate.
These days, when loading something like the health app I get a series of three different screens, rather than just landing at the destination it knew o wanted to start at. It is idiocy of the highest order. Why show some series of random screen transitions while starting the app? Somebody who has no clue about UX programmed that piece of crap, and then an entire team put up with this behavior. I dearsay that if this shipped under jobs there would be a director level firing to stop it.
Same BS happens with Apple Maps. If you launch the app and it remembers that an hour, day, or two weeks ago you had your phone in a particular orientation forever ago, it slowly rotates the view pane over 1000-2000ms from you ancient view pane as if you've been waiting patiently over two weeks so that Maps doesn't suddenly disrupt your view...
Animation can be helpful but at some point a half-wit VP shoved it into everything Ruth disastrous results and Apple is still recovering. Liquid Glass is a similar disaster of incompetence being promoted far beyond capability.
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.
Possibly a consumer air dryer problem, something-something safety. Check professional ones like Parlux, the one I checked has 2 dials: airflow and temperature. Turns on by air dial. They are also conveniently under the thumb so you can adjust without looking.
Yes it's safety related. Turning the heater on while the airflow if off is a sure way to start a fire.
It could be fixed with a relay or a solid state switch on the heater, or with a multipolar toggle on the airspeed. But that's several cents more expensive than making it turn on at the heater switch.
I imagine itās similar to why a fan starts at max. Eg: 0->3->2->1
Something technical made it easier to implement.
The Dyson Supersonic?
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.
Or another bug seen in the wild: the image rotates opposite to the buttonās icon label.
We like buffering of keystrokes or gestures when the system is completely reliable, exhibits reasonable latency and low jitter in its latency.
Even in unstable or high latency I like the buffering. Iām thinking of a remote shell, where you want to type a command blindly, and see it appear seconds later, because keys got buffered in the Internet pipes. Without buffering it would feel awful, having to wait a full roundtrip per keystroke
please, use mosh, if this is available for you
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.
Now I am imagining a typewriter with just two huge round buttons, next to each other horizontally, and a spacebar bellow them:
A press of each round button rotates the typing ball accordingly, pressing the space prints the chosen letter and resets the ball to the neutral state. This whole thing should probably be electric lest you'd have to press the space bar by smashing it with both fists.Now remove the spacebar, combine the two buttons into a single one for "tone" and adapt it to morse code. All the buttons still do only one thing and now there's only one button!
And, you don't have to worry about what to do in the case that someone hits the "rotate ball" button while it's still rotating.
Apple still did it best: https://www.youtube.com/watch?v=9BnLbv6QYcA
The power button of my pc also has the job to tell wether the PC is turned on. So do bulb switch buttons that have a pilot light, and so on
Yeah, sometimes, when I am sitting before my computer and typing comments on the Internet, I have a thought: "Is my computer turned on?" With a quick glance under my table I can reassure myself that it is indeed on and continue using it. No idea what I'd do without that small blue LED.
The pilot lights are slightly more useful in those stupid cross-wired double switches that for some weird reason implement a sort of XOR (or sometimes XNOR because why not) gate for controlling a single light: if it's on, then the bulb is depowered and you can safely change it without turning off the entire power rail. But then one day the pilot light itself burns out...
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.
That's a great example of bugs in overcomplexity. The requirements were relatively simple, but they went for a full-on multitasking OS with all the complexity that entails.
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.
Using AOSP-based Android roms, I haven't noticed any big changes in years. In current "android 16" and my old "android 10" device one couldn't really tell a difference. Very simple UX, no bloatware apps, no hidden drawers coming out from sides.
I've tried the vendor ones by Samsung, OnePlus etc with fresh devices and this Android experience really is awful.
I wish there was more love for more vanilla forms of Android. I would trade more simplicity out of the box and regular software updates over the current situation.
Personally I'm blown away by Motorola options in the budget range. For raw value alone there offerings are hard to beat.
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?
Software patents? Care to elaborate?
I don't have any specifics, but based on experience, it feels like software giants like to patent what a lot of people would consider obvious wins (such as interruptible animations) if no other company happens to be doing it, and it felt like this would be something where that could be the case.
That said, I can't seem to find any evidence of this particular thing being patented to support my case, so it's probable that I'm wrong.
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.
You are talking about the label on the button. The button does one thing. The label does one thing. You put the two together and you have UX.
I think this is a distinction without a difference. Imagine an array of buttons. What do they do? The label is intrinsic to the button. I understand this is a perspective. But, taking this to another level, perhaps an absurd one,the button only sends messages and ideally reacts to show it's been activated.
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.
> But the article got ahead with explaining how the Nothingās solution was better.
No? It makes the opposite argument.
Then I definitely need to get some caffeine I guess *yawns*
> 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.
Am I misreading this?
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.
Some years ago, I attended an informal demo of some application we built. The engineer who had worked on the UI was showing an animation of the initial splash screen. It was only 5 seconds or so but I asked him whether there was an option to disable it. He said there wasn't. I then asked if he didn't think that a user, running this many times, was going to get very tired of seeing it run every time and want to just show the home window immediately on start. I said I knew I would. I told him that regardless of how "cool" it looked, when you see the same thing a few times, it can become annoying leaving the user pissed off because its out of their control. I don't know what happened after that. Since I didn't have any authority to request changes, I was probably ignored.
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!
Similarly, why don't photos get auto-straightened, maybe with an option to revert to original? I spend too much time aligning the horizon properly on snapshots that I took while cycling. The phone even has the data from the rotation sensor, so this should be fairly easy to implement.
This is so true. Sorry you got downvoted.
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.
It's not really a question of how many taps they support, but how fast.
This same issue also seems like it would prevent you from quickly double-tapping the button to turn an image upside-down, a much more common use case.
Not prevent, just not provide very responsive feedback, right?
I don't know, I understand the principle, but I don't see how you can determine the value of a principle outside of a specific context.
Even for accessibility, we can't target every context in the name of being accessible. We still have to pick which contexts of inaccessibility we'll need to support with more attention.
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.