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.
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.
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.
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.
If you want to achieve low-latency input, "act on first edge, then ignore for the switch bounce period" is a far better approach. It also conveniently solves the "press, then release within bounce period" problem where an averaging algorithm would completely ignore the button press.
And even with no additional latency, 5ms is perceptible in some cases anyway. Microsoft Research has a video demonstration:
For example, smartphone app developers routinely run their apps in emulators first to make the development process more convenient, only running it on a physical device for confirmation when the work is basically done.
Many embedded developers would kill for something similar, and we're already seeing the start of it with platforms like Wokwi. Being able to do integration tests without the physical device itself is an absolute game changer.
I know you mean "debouncing" but I love the autocorrect. Like the button is some almighty authority that Denounces noisy signals.
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?
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.
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.
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.
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.
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.
The motion itself indeed gets picked up intuitively by the brain.
Okay, I'm convinced that picture rotation should be animated to the exact degree that achieves this.
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.
___
In fact, "being overly hostile" is exactly how you probe to see whether your suspicions are correct.
Sea lioning exploits the gap between what would be a real human thing to do and what still passes as what a real human would do.
So to get useful data, you need to modulate parameters so that people end up outside of that gap window.
Essentially you're probing for genuine Human-ness by creating a context in which the bad faith action space is no longer overlapping with the genuine human action space.
This works, because genuine humans have this amazing ability to reconcile and actually genuinely resolve misunderstandings. Something that is fundamentally impossible for bad faith actors.
(This should not be understood as "just be overly hostile" because simply being a dick doesn't provide any data at all.)
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?
Other way could be to actually visually indicate action queue depth.
Google, Microsoft, Amazon, Netflix, Meta. Is there even one software company that does software UX well but not on Apple's platform?
On average it is has same amount of crappy UI experience, just in different places.
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.
Record actions until interrupt.
Animation should not be considered interrupt.
An Error message should be treated as interrupt.
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.
> 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.
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.
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.
Idea being that for user it is less frustrating to wait for animation to end, than to see some hourglass/waiting indication.
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)
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.
*-----* *-----*
| | | |
| ● | | Ω |
| | | |
*-----* *-----*
[================]
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.