Yes many do. Especially the snappy part. I've removed a lot of eye candy animations coded by well meaning devs at the request of users who care about nothing more that speed.
Animations can be a nice first impression, but if you use the app daily e.g for work or data entry you know how to navigate and you want as close to instant response as possible.
Maybe a smart pattern is animate in the early days for new users then transition into a more jarring and snappier world as they become regulars.
I've never seen a UI animation that I liked, no matter how "quick" some designer thinks it is. Animations are just avoidable latency. But the nice thing about CSS animations is the "cascading" part. CSS is designed to be overridden, and my browser still fulfills its traditional role of "User Agent". Animations get disabled like every other annoyance. If CSS animations didn't exist then designers would probably find some more obnoxious way to implement them.
CSS animations/transitions are very smooth (opacity/transform) and make it easy to implement really cool effects once you understand how they work.
The biggest drawback and problem I encountered is that Chrome is very, very, bad at maintaining rendering quality in certain situations. The problem is not that the element you are trying to animate gets blurry (eg. trying to animate text, it will be rendered on GPU, thus moved to its own layer, it might become blurry sometimes), but the problem is that OTHER elements on the page are affected. Try to scale-in the logo in top left of the page? Great, now the text in right sidebar starts jiggling while the animation is running. Want to turn around an image on hover? No problem, only that the SVG icons on the page now have a line artifact through them. Those issues only happen in Chrome, which seems to try too hard (and to have also tried) to optimize for performance over quality.
Whilst I wholeheartedly agree, there is a quick fix for some of the issues: adding the will-change property can significantly improve chrome performance. Especially for animations that might run a lot
The `will-change` property is just a flag for the browser to move the element to its own layer, it does not fix the rendering issues. I tried all fixes I could find on the internet, nothing worked. Just Google for "blurry animation chrome".
Some suggested fixes are:
-webkit-font-smoothing: antialised;
backface-visibility: hidden;
transform: translateZ(0);
-webkit-font-smoothing: subpixel-antialiased;
But most of the times they don't do anything or just make things worse. The only solution is usually to move your elements fractions of a pixel until Chrome is happy. The problem is that if you have a responsive website (or a container that is scaled with a transform), it's impossible to have all elements pixel-perfect aligned on all resolutions. Although they look fine when rendered normally, when adding animations things will get blurry. And because it does not happen in other browsers, it means it's not a limitation of the GPU or monitor to display sub-pixel content.
Wait, is it really true that "ease-out" is intended/best for animating elements moving IN from off screen, and "ease-in" for animating elements moving OUT of screen from on screen?
I've been using them opposite/wrong (as their names led me to) all along?
The name refers to easing into or out of the animation. You want to ease into an animation for something leaving the screen (train leaving the station) versus one entering the screen (train arriving)
Few of the explanations of ease-in and ease-out I find on top page of google results even now explain this very well. I wonder how many are getting it wrong.
This is cool, but... to say animations and transitions are overused on the web is an understatement.
Distracting, annoying, slow, increase webpage resource use, induce nausea in a fair number of users... ask yourself, are they really necessary or do you think they just look "cool"? If it's the latter, probably don't use them.
And then you try implementing any of them and realise that even the simplest examples often break in subtle and not-so-subtle ways, have hidden and not-so-hidden restrictions, may or may not be hardware accelerated, may or may not break layout, cause reflow and/or repaint, can't be stopped once started...
My favourite example is, of course, animating height: auto and width: auto. A detailed discussion on why it's not possible and the (rather insane) tricks you have to do to animate these two properties is here: https://css-tricks.com/using-css-transitions-auto-dimensions...
You should only animate GPU-accelerated properties (transform, opacity) if you care about performance and responsiveness, or in the worst case some properties that trigger paint (color, backgroundColor, etc.).
That's true, there are some limitations. Sometimes you can still do those sort of things in CSS if you set the target values using JS (instead of changing height to 0, change scaleY to 0 and translate up the elements from below with the height of the element that was removed). If all elements are same height, or the height is known beforehand you can just hardcode that translate value into the animations.
Whenever talking about UI animations it's important to observe the Best Practices for Response Times and Latency [1] especially if the animation is in addition to a network request. Latency over 300ms might result in a degraded user experience depending on the situation.
>0.2 sec gives the felling of instantaneous response
This is obviously false. Ideally test with an Arduino or other hard-realtime capable system, but assuming your computer doesn't have absolutely terrible latency you can still test with it. Disable your compositor if you're using one, and use a low latency terminal with uncapped framerate like xterm.
The popular method of running "sleep 0.1" alone is not actually a fair test, because a newline is printed immediately on running the command, so you might just be seeing the flicker and not the latency. A better method is comparing:
Is there a good rule of thumb for how to transition new elements into the DOM? Right now, if I have an overlay, I mount it offscreen, and then do a `setTimeout(..., 0)` callback that transitions the overlay into view.
This works, but it seems a little glitchy in some environments. I'm wondering if it's too much to make DOM modification and then trigger a transition in the next tick.
SetTimeout with 0 is a hack, you should have much better result with requestAnimationFrame when it comes to animate something. Also changing class in your DOM and perform the animation in CSS is the way that works best today. Hopefully this will change when the animation API will have better support from JS: https://developer.mozilla.org/en-US/docs/Web/API/Element/ani...
You mean the element is moved offscreen, and has display: none; applied? And now you want to move it onscreen.
Do it entirely css. if you use a have a keyframe animation applied and remove display:none on clicking. The animation will fire immediately. Unlike trying to transition it without using keyframes.
Typo aside, I greatly prefer a stiff, snappy UI. These kinds of animations look nice and smooth at first, but get in the way after a while. I just want to type some text and check a few boxes, not wait for animations to finish so the UI is responsive again.
The counter intuitive thing to keep in mind here is that the best animations are subtle, and very quick. There's a balance to strike, but good animation can make the snappy UI give just the tiniest hint of motion and smoothness, without detracting from the experience at all. Animations are meant to be subtle hints to guide the viewers eye, not flashy eye candy.
Long animation times are _such_ a common rookie mistake, because the UI dev (or their manager) wants to notice the animation, when in the vast majority of cases, it would be better for the animation to be nearly invisible.
IMO animation should only be used in cases where the change of state is inherently difficult to understand. Animations help users understand what happened after an action.
I use a programme picker that is a poor Netflix clone. Selecting down to the next row is immediate, and selecting right for the next show within a row also immediately jumps.
Vertical and horizontal smooth scrolling (a type of animation) would improve the UI (caveat: unless too slow of course).
1. bounce of badge when message received and badge number increases (no sound). A la Mac.
2. After modality viewing item in list on mobile, when returning to list highlight the item to show what you have just edited (easy to lose place, animated highlight helps show new summary).
3. On closing a drawer, animate the closing so you don't lose view of next item.
I loath animations (and I really loath coding them) but I will use them if I think it improves the UI, if they are fast, and I don't use them for "design" (I'm an engineer not a designer!).
