Posted by nozzlegear 17 hours ago
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?
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?)
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.
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.
Now that I'm wondering. How does iphone mitigate this problem?
Other way could be to actually visually indicate action queue depth.
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)
Idea being that for user it is less frustrating to wait for animation to end, than to see some hourglass/waiting indication.
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.
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.
Record actions until interrupt.
Animation should not be considered interrupt.
An Error message should be treated as interrupt.