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 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.
How about when users accidentally click too much, or they believe the first click didn’t register?
I am still reminded of a keynote where Steve Jobs was demoing how much faster PDF documents would display on the newer macOS. So he had engineers put a button in for him to click that would scroll through the PDF on the screen, and he accidentally clicked it more than once. Steve wondered aloud if it would scroll all the way through twice… and sure enough, it buffered the process! He had to wait for it go all the way back up and scroll through a second time!
Steve saved grace by telling the audience that, even with moving through the document a second time, altogether it was still faster than PDFs had been in the last version of the OS.
I'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.
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.
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.
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 is a more general Android problem where it registers a single tap sufficiently to show a button press animation and vibrate and then ignores it because the tap wasn't held long enough.
It's not so simple. There are times where you intend to tap one thing and something else appears underneath your finger instantaneously. So sometimes while rendering a layout you want to stop accepting input.
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.
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?
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.
This isn't unique to touchscreen interfaces. I have the same frustration when performing a sequence of keyboard commands and the OS can't keep up (or some other application or unwanted notification pop-up steals the focus).
If you're a button, you have one job: to transmit Morse code from the finger to the machine, Morse code representing a complicated POSIX shell command. And also to power down this entire one-button terminal with a 3 second press, power it up on any button press, with a firmware reset if powered up by a 30 second press.
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.
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 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
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!
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!
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 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 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.
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.
> 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.
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.
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.
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.
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.