Animation: a little goes a long way 9

Easing curves

I’m a big believer in the details make the difference in how a product is perceived. One of these details is animation. “Animation” may sound like a dirty word to those wary of years of flash intros and websites with questionable, unnecessary use of movement, but used the right way can enhance your product in subtle but important ways.

These days of course we already see user interface animation used liberally in mobile apps and across the web, thanks to the ease of use of libraries such as jQuery and more prevalent support for CSS3 transitions. This post will be somewhat technologically agnostic, but rather concentrate on how to make good use of animation. Used well, a little animation can make your product feel tactile, solid and polished.

I see 4 key considerations when deciding if and how to use animation:

1) Should I use animation at all?

To answer this, I would first ask myself: does it help the user understand what’s happening in a specific interaction scenario? An example of this could be on a mobile device with a navigation list that opens up from a “hamburger” menu in the header. Maybe the menu button links to an open navigation at the bottom of the page. Without animating there, the page simply jumps to the bottom (view at mobile width) and the user might feel lost. A quick animation while scrolling down helps the user understand where on the page they are. In this particular case the length of the page might also be a consideration on whether to animate or not.

Will the animation get in the way or unnecessarily delay something the user is trying to achieve? I sometimes see simple hover states on buttons using an unnecessarily long animation to change colour or lift up, etc. Most of the time, I would prefer that these types of interaction would be better served with a simple on/off state.

2) Does the animation make sense?

Even though we design for the screen, if it doesn’t feel right physically, maybe it needs to be adjusted or taken away. An example of this could be on Paravel‘s site. Though nicely implemented, I feel the hover animation should “lift up” rather than “push in” as it currently does. The “pushing” could be reserved for when the user actually clicks.

Paravel hover

3) How should an animation be implemented?

(Hint: this involves easing)

More often than not, I see animation implemented in a rudimentary way. For example, when opening an expandable menu on a mobile device, a linear animation (view at mobile width) might be used that lasts half a second. Yes, the animation explains what happens when you open a menu, but it feels wooden and somewhat awkward. All it takes to make an interaction like this feel really polished is some tweaking of the duration and “easing”.

For those of you who haven’t come across the term, at a basic level, easing describes how the animation speeds up or slows down over time — in my opinion this is critical to pulling off a nice feeling animation.

There are many standardised ways to ease, such as “in”, “out”, “in-out”, “back”, “elastic”, “bounce” etc. The site has a great overview of all of these, with code examples for both css and javascript. curves overview

The scope of this post doesn’t encompass all of the different ways you can use these, but know that tweaking the duration of an animation from half a second to 300ms with an ease in and out can make a really big difference to the feel. In terms of my previous example of a drop down menu opening, this kind of easing in and out would make the interaction feel silky smooth. When hiding the menu, perhaps an “ease in back” could be used to pull the menu slightly in the opposite direction first, then send it out quickly. A masterclass in use of subtle, clean animation and easing can be found in the iOS game Letterpress.

Etch apps

There are many other good examples across the web, but a couple of recent ones that stand out to me are the open & close navigation on and the left & right page navigation on On the latter example, you will notice the subtle difference between the left and right button animation. Pressing right to go forwards results in a smooth ease in & out, while left to go back presents a slight ease back first, emphasising the direction change.

USA Today

I would consider the USA Today site as being on the edge of just enough/too much use of animation, as it is a fairly heavy site. This issue leads on to …

4) Performance & compatibility

There are some caveats with using certain types of easing, like “elastic” and “bounce” due to their processor-intensive nature they may not appear smooth on all devices & browsers, so some caution (and taste) should be used.

In general, animation with javascript and most commonly jQuery is the most browser-compatible way of doing things. CSS3 transition support is getting better all the time however and it’s common to at least progressively enhance css with transitions if not going all the way and providing javascript fallbacks for these too.

What now?

I hope this post has brought some awareness to the way animation is and can be used in web sites and apps. I haven’t gone into too much detail but would be happy to discuss further in the comments! Go forth and animate, responsibly.


Of course, I’m also a sucker for really nice little details that don’t necessarily tie into a particular interaction. I think it’s sometimes OK to go a little crazy, as long as we’re not distracting or delaying the user from their goals on the site.

Will Hindson

Flere artikler av Will CV

9 kommentarer

  1. Great read. You could turn the first question and ask “Why should I not use animation here?”. Almost nothing in nature is staccato or disappears in zero milliseconds.

  2. Thanks Tor, that’s an interesting point. While I’m the first to advocate the use of animation, I do find myself checking more and more if it’s really necessary or even detracting from the experience. In the case of hover states, for example, it often feels much snappier and cleaner without a fade or lift. I think it’s key to make sure if an animation is used, that its an appropriate length. This will usually be very short in the case of a hover!

  3. I think we as designerds and developers would like everything to happen in zero milliseconds. That’s not the case for the regular user though. But there is a fine line between instant and sluggish. So a lot of animations might just run in 100-300 milliseconds.

    Always test animations on mobile, nothing is more frustrating and annoying than sluggish, choppy animations on a mobile device where everything around the browser feels snappy.

  4. I would make a variation of your ‘NB:’ the number 5 on your list. Touch-screens has completely changed the role of animation IMO. Consider an interaction like pull-to-refresh. It’s not only an effective UI, how it’s animated is also key in what gives the sense of direct touch/response on the iOS-platform. And eventhough some people might disregard of the rubber-band effect as unholy, skeumorphic non-sense I think there’s something to little animations like that. Especially on our touch-screens. The little UI-elements that hardly serves any other purpose than to be fiddled with. Idle hands has always gravitated towards something to play around with and these little reactions/animations gives the sense of somthing a little more tangible in a poking-at-glass-surfaces world. And back to to your final ‘NB:’-point, while seemingly irrelevant details, I think these animations becomes a fairly important part of the overall experience – like the leaves when you resize the window on or the way the icons bounces out when you add something to the timeline in Path. Love’em!

  5. … or Flipboard. Where the whole experience is basically based on a little animation.

  6. @Johan Completely agree regarding things like the rubber band effect – these kinds of details are not necessary but absolutely make something feel so much more solid and tangible. Consider the difference between Firefox and Safari / Chrome on OS X – without the rubber banding, Firefox now seems wooden when scrolling. Admittedly this is an interaction that was taken back to the desktop but it’s the kind of thing that you don’t realise you’ve missed until you have it.

    My post was really focussed on the details of how these animations feel – in retrospect more about responsive web sites than apps, but of course applicable to both. This “new” breed of pull to refresh and rubber banding interactions are using easing liberally and usually to great effect – when tweaked to feel just right they can add so much to the experience.

    There’s also a lot I didn’t cover – scrolling animation effects (parallax etc), touch specific animation – the list goes on. I think the overall message I was trying to convey was that I see a lot of animation out there that has just been slapped on, without too much thought. It’s all about the tweaking :)

  7. Excellent read – instead of encouraging old-school fanatics to continue on their “anti-animation” war-path (don’t know if there’s any left), your piece deals with it from a factual/reasoning point of view. /me likes.

    My take-away; animated effects are not bad – it can enhance and make the overall UX more (1)intuitive and (2)professional/memorable (lifting the desirability factor in a subtle manner). Just make sure to apply it in the right doses – as it may become a matter of life and death (UX-speaking).

  8. Thanks Ammar – I think it’s now generally accepted that tasteful animation can help lift UI design, and given that designers and developers everywhere (of all levels of experience) are making use of it, quality control shouldn’t be an afterthought.

  9. Dala and question her about her unusual interest
    in the human body. In case you have PSN codes, you get access to video games
    you will otherwise pay money for. When considering a portable generator look at the type
    of fuel it uses and determine which fuel source would be easiest
    for you to obtain in an emergency.

Skriv en kommentar

  • *

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>