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?
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.
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 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.
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.
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.
> 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.
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.
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?
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.
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.
> 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 disable all animations everywhere (Android, Windows, Gnome) because I hate that they make me feel like I'm losing time waiting for something that could be instant, and they sometimes make me dizzy. I'm particularly exasperated that iOS doesn't offer that possibility.
But rotating an image is one of the rare use cases where I do want the animation. It makes me see what action happened, with which rotation angle, without having to think twice.
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.
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.
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.
"We cannot risk looking outdated". So weak management, probably.
But also talent availability I suppose. If there's a new trend, the pool of people you can hire include many that are in on that trend.
UI frameworks too, probably. The modern thing™ does the modern thing™ and you do want to be on the modern thing, because you fear that only that receives security fixes or whatever.
If UIs today still looked exactly the same as Windows 2.0 or System 7 or CDE people will be bored to death.
Aesthetics come and go and come back, it's part of how humanity worked for a few centuries already.
Do I need to be entertained by my butter knife, mop or screwdriver?
I really don't think that "keeping people entertained" is a sensible goal within the context of building software as tools and not software-adjacent Art.
Which is not to say that I would not want a great and polished experience, but that is not equivalent to "being entertained".
___
It would be nice if not everything one interacts with would try to get some sort of emotion out of me. Bring back being bored.
Make-work. Managers needing to justify their promotions with a new way of doing things. Whole teams are given a reason to stay employed. OS and device obsolescence is achieved. A win all around, save for the consumer.
What’s wrong with flat UIs? Skeuomorphic designs have served their purpose of helping people get used to computers, but now that is no longer necessary.
That is a valid opinion to hold, however, the question of "what is wrong with X? Y is outdated and over" is
a) a different statement from "I prefer X"
and
b) pretty low effort, trivially to Google (or ask AI) and generally a bit on the ignorant side
A better reply would not just have said what it said but contained actual wonder about the topic. Like this, it's just indistinguishable from engagement bait.
> pretty low effort, trivially to Google (or ask AI) and generally a bit on the ignorant side
I know the most common reason why people prefer skeuomorphic design (the visual metaphor), which is why my original reply directly addressed this complaint by saying that it’s no longer relevant. Some other complaints I’ve found online are about specific bad instances of flat design rather than flat designs in general. Therefore, I am asking about reasons that don’t fall under these two categories, which I haven’t been able to find.
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.
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.
There are many types of disabilities. If "power user" means "someone who doesn't use defaults", then people with disabilities are actually more likely to be power users.
Being fast does not make you a power user. "The button works when I push it twice" is a reasonable expectation of a device by default. If that weren't the default, then most people would have a worse experience with their phone.
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.
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.
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.
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.
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).
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.
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 not sure exactly how you're misreading it, but you are.
The Nothing isn't executing all the taps, some are blocked by the animation. It is responding visually and haptically to all of the taps, but some are blocked from doing any work by the animation.
You also said the Nothing was 6 taps but I'm not seeing anywhere the article says that. I believe it was 8 taps on both.
Okay, that one is on me indeed. I’ve re-watched it at 0.5× and he does make 8 taps indeed. Apparently, only the first and the last are registered then. Sorry for the confusion!
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.
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.
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.
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.
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.
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.
I am still reminded of a keynote where Steve Jobs was demoing how much faster PDF documents would display on the newer macOS. So he had engineers put a button in for him to click that would scroll through the PDF on the screen, and he accidentally clicked it more than once. Steve wondered aloud if it would scroll all the way through twice… and sure enough, it buffered the process! He had to wait for it go all the way back up and scroll through a second time!
Steve saved grace by telling the audience that, even with moving through the document a second time, altogether it was still faster than PDFs had been in the last version of the OS.
I 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.
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.
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.
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.
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.
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 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.
But rotating an image is one of the rare use cases where I do want the animation. It makes me see what action happened, with which rotation angle, without having to think twice.
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.
Now that I'm wondering. How does iphone mitigate this problem?
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.
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.
The Flat UX fad was objectively terrible on just about every metric I was taught, but people were actively pushing for such designs.
FOMO for sure is one of the driving factors.
"We cannot risk looking outdated". So weak management, probably.
But also talent availability I suppose. If there's a new trend, the pool of people you can hire include many that are in on that trend.
UI frameworks too, probably. The modern thing™ does the modern thing™ and you do want to be on the modern thing, because you fear that only that receives security fixes or whatever.
I really don't think that "keeping people entertained" is a sensible goal within the context of building software as tools and not software-adjacent Art.
Which is not to say that I would not want a great and polished experience, but that is not equivalent to "being entertained".
___
It would be nice if not everything one interacts with would try to get some sort of emotion out of me. Bring back being bored.
It's possible to have a flat style but have buttons that look clearly like buttons, and elements that have shadows and colors.
a) a different statement from "I prefer X"
and
b) pretty low effort, trivially to Google (or ask AI) and generally a bit on the ignorant side
A better reply would not just have said what it said but contained actual wonder about the topic. Like this, it's just indistinguishable from engagement bait.
I know the most common reason why people prefer skeuomorphic design (the visual metaphor), which is why my original reply directly addressed this complaint by saying that it’s no longer relevant. Some other complaints I’ve found online are about specific bad instances of flat design rather than flat designs in general. Therefore, I am asking about reasons that don’t fall under these two categories, which I haven’t been able to find.
The parents question seems reasonable to my non designy mind.
No on the Internet.
Especially not on the sea-lion infested HR-world Internet, in which trolling has evolved to exploit good faith directly.
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.
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.
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)
> 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.
Being fast does not make you a power user. "The button works when I push it twice" is a reasonable expectation of a device by default. If that weren't the default, then most people would have a worse experience with their phone.
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 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.
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.
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.
Eh, it's a pretty trivial problem, comptometers have it figured out more than a hundred years ago.
iOS is no better. Sure everything is intuitive but it's going to get a redesign so next year you are going to have to learn everything from scratch or a feature you use often will just break.
I've tried the vendor ones by Samsung, OnePlus etc with fresh devices and this Android experience really is awful.
Personally I'm blown away by Motorola options in the budget range. For raw value alone there offerings are hard to beat.
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.
No? It makes the opposite argument.
> 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?
The Nothing isn't executing all the taps, some are blocked by the animation. It is responding visually and haptically to all of the taps, but some are blocked from doing any work by the animation.
You also said the Nothing was 6 taps but I'm not seeing anywhere the article says that. I believe it was 8 taps on both.
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!
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.
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.
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.