zlacker

>>jakela+(OP)
Personally I would even speed up these animations. 300ms is too high. I prefer animations that are almost imperceptible. You might even only notice them if you take them away.

Anything longer than that I consider too slow.

>>prisen+Tn
I used to go for 250ms, now I go for 200ms. I find that about the sweet spot for UI transitions where it helps you to understand what’s changing and how and why. And if it doesn’t meet those criteria, don’t transition it.

200ms is also nice and short to write in CSS, .2s. I contemplated shorter, but I found that by 150ms a transition can start to feel like it’s a mistake, a brief rendering glitch, especially if the first few frames of the animation are dropped, as can be common (.2s is already down to only ~10 intermediate frames). It’s too short to get the benefits of an animating transition, but too long to be or look or feel instant.

>>chrism+Sv
I think if the animation "helps you understand what's changing and why", sometimes that's a sign that the change could be redesigned - moved to a different part of the screen, for example - so that it becomes clearer without needing to be animated.

For example, if pressing a "Save" button makes a "Save successful" toast appear on top of the screen, it's tempting to animate it in, so that the user notices it. But it's better to replace the button text with "Saved" and gray it out, which achieves the same goal and feels great without any animation.

>>cousin+Ox
In general I think toasts are a borderline antipattern, particularly those presented as a chance for the user to undo some action that they accidentally triggered (doubling the panic since now the undo has become a time bomb). Just don’t make the consequencial action so easy to trigger in the first place and where relevant (on iOS or desktop) support the standard undo stack.

>>cosmic+yE
Toasts on large displays are definitely an anti-pattern, they're just too far from where the action that triggered them actually happened.

On mobile it's a bit different, because often you don't have the space to put an "undo" button or status text right next to the thing you just did. So you put it at the bottom or something in a toast.

Still not good, but more justifiable.

Also iOS does not have reliable undo actions. Android does, but on iOS there isn't an equivalent. No back button. Well, maybe a back button but definitely not required and not enforced in any way.

>>const_+K01
Still iffy on mobile because the way the device is being held can’t be assumed. The area the toast appears is very easily hidden by a hovering thumb for instance, especially for people with larger hands.

Undo and back are conceptually similar but different. On iOS, consistently anywhere you can enter text you can give your phone a quick shake (similar to a person shaking their head “no”) and it’ll offer to undo the last edit. Many apps like Reminders use this for actions like item completion too. There’s a native undo stack you can use to leverage this as a third party dev. There’s also a gesture that can trigger this but I have yet to commit that to memory.

Android does not have an undo gesture. Some skins (like Samsung’s) implement something similar but it’s not consistent and it’s limited to text editing.

For going back, all apps built with native iOS UI toolkits have a swipe gesture that goes back to the previous screen. Cross platform apps built with other frameworks are notoriously bad about not implementing this, though. It’s true that there’s no cross-app back gesture, but swiping back and forth on the home bar is a rough approximation.