| 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. |
| |
| ▲ | cousin_it 6 days ago | parent | next [-] | | 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. | | |
| ▲ | cosmic_cheese 6 days ago | parent | next [-] | | 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. | | |
| ▲ | const_cast 6 days ago | parent [-] | | 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. | | |
| ▲ | cosmic_cheese 6 days ago | parent [-] | | 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. | | |
| ▲ | const_cast 6 days ago | parent [-] | | IME it's the exact opposite. That iOS undo action is more or less theoretical - the apps that support that are some of Apples... And that's it. The android back action is universally supported. Its literally a button, still, to this day, persistent on your screen by the OS. Also, the "swipe back" action on iOS is more or less fake. Its applied so inconsistently it might as well not exist. In my head "back" and "undo" are usually the same thing. iOS has a good interface, but this is one glaring blind spot they missed to Android and browsers. It actually makes iOS quiet frustrating to use. Also, barely related: but the "shaking your device is like shaking your head no" thing is the stupidest thing I've ever heard in my life. I'm sure Apple thinks its very intuitive and good design, but it's really, really not. That's one of the least discoverable things I've ever heard. Apple please don't do that. | | |
| ▲ | cosmic_cheese 6 days ago | parent [-] | | Swipe to go back support is pretty wide if you select for iOS-first apps (I do). It’s glaring when I try to use it and it’s not there, so when that happens I’ll either go find an alternative or drop back to the web app (where Safari will definitely implement it). My Android devices all have the gesture bar enabled because the old style button bar is an eyesore and easy to trigger accidentally (Android’s swiping from the right to go back is also too easy to trigger as a right-handed person, but that’s another story). My metal model for the undo/back split actually follows desktop browsers. Cmd-Z isn’t going to undo navigation while Cmd-[ will, and so the two are separate and distinct. |
|
|
|
| |
| ▲ | MrJohz 5 days ago | parent | prev | next [-] | | With saving, I usually add a confirmation directly next to the save button, so the save button itself doesn't change state (people often like pressing save multiple times!). But even then, I find a little bit of animation that moves the "saved" text away from the button to indicate where it's come from can be really helpful for intuitively connecting the two interactions. The animation should be fast (100-150ms max, often as low as 75ms), and subtle (just a slight step to the side), but it gives the user more of a feeling about what's happening. | | |
| ▲ | account42 3 days ago | parent [-] | | > With saving, I usually add a confirmation directly next to the save button, so the save button itself doesn't change state (people often like pressing save multiple times!). There is no problem with the button changing states as long as it only happens after the current document state was successfully saved and becomes active again when you make changes to the document. That way the button doesn't represent the outcome of some action but the sate of the document - unsaved changes = button enabled, no unsaved changes = button disabled. |
| |
| ▲ | Larrikin 6 days ago | parent | prev [-] | | The toast doesn't block the user from saving again in quick succession |
| |
| ▲ | 6 days ago | parent | prev [-] | | [deleted] |
|
