Stop Using Gratuitous UI Animation(medium.com)

over 7 years ago from Sophie Paxton, UX Designer

  • Joe Blau, over 7 years ago (edited over 7 years ago )

    I think this is becoming more of an design trend as well. It's definitely been accelerated by Material Design which has lots of animation at it's core. I would say one of the leading design teams in building interfaces with animation correctly is Stripe. This blog post on improving the payment experience with animations as well as this video by Benjamin De Cock at CSSConf Australia really show that they understand how to do UI animations correctly. In the @bdc video, He lays out 4 guidelines which I've adopted in my own designs and prototypes.

    • Animate exclusively opacity and transform
    • Keep your animations fast (usually around 300ms)
    • animate things independently
    • always use custom easing

    I'm still a fan of animation because it can help maintain context (demonstrated in this post in the last design), distract a user while information is loading (pull to refresh animations), or provide a humanistic visual response as demonstrated in the "no" animation. I just think that it's also very easy to over use and cause slow, nauseating experiences. I know a few people that turn off all animations / parallax on their iPhone for that reason specifically.

    16 points
    • Sean LesterSean Lester, over 7 years ago

      I'm getting into UI animation a bit here at Match, but have very little idea what I'm doing - so this is helpful. Anything else you can point me to, perhaps?

      I threw this together yesterday super fast (and have since rebuilt and refined it in Edge Animate so that the devs can pull values from the JS output) to show how a new message might animate in. http://i.imgur.com/rApJFbK.gif

      2 points
    • Dirk HCM van BoxtelDirk HCM van Boxtel, over 7 years ago

      Note about animation speed: it depends on what you're animating. If it's a small visual, between 200 and 250 is great and looks "instant". 300 fits some bigger animations, and you can go all the way up to 1 second of animation for things like "scroll to top" or other page-wide animations.

      Easing is just as important on this as the speed.

      The reason speeds should vary, is because of the purpose of an animation.

      Let's say you have an index at the top of your page, and when you click it, you animate the scroll down the page to get to the content. Now ask yourself: why am I animating this?

      In the above example, animation is used to convey a sense of position. If you go too fast, a user won't have any idea where on the page they are, and the animation was useless and might as well have been instant.

      Compare this to a hover state, where you just want to show something is interacted with: as long as it's clear almost instantly that someone is hovering over it, the app will feel responsive. The slower you animate however, the less likely the user will notice the state.

      Again, not dismissing "usually around 300ms", because as a general rule, that's just fine. Just felt like expanding on what the word usually means here! :)

      2 points
    • Marc EdwardsMarc Edwards, over 7 years ago

      I am a huge fan of Stripe and @bdc’s work. I agree that they’re such a good example of how to get it right.

      Animate exclusively opacity and transform

      This point is mostly about the web and CSS, because opacity and transform can be exclusively done on the GPU. That is, they don’t trigger a browser repaint of any elements. And that’s why they’re typically the best way to get 60fps results.

      But, for native the rules are slightly different. It’s the same in that you want to avoid repaints, but what’s possible is slightly different.

      4 points