This is going to be an article about motion in Interface Design. You'll hear me rambling about the implications of animation, when and what to animate, and how to be responsible with it. None of what I say is set in stone. I'll just try to give some general advice for handling animations in UI.
However, you won't find any actual code snippets or step by step tutorials here.
Before we start: Being a web developer, I talk a lot about websites, but this can be applied to all kinds of visual UI.
Some of my examples are abstracted wireframes or codepens, but all have been seen in real world projects. Also, most of the codepens are not mine. Huge thanks to their respective authors!
Now make yourself comfortable and grab a cup of tea. Let's start! ☕
A User Interface is always an abstraction. It abstracts a problem in a way that humans can perceive and understand, preferably something that we're used to (physical buttons, Skeuomorphism, tangible Material). What we're also used to is motion. Seeing where things come from and where they go help us orientate not only in the real world, but also in abstract spaces like websites.
Animation in UI can be a great help for your users to understand your layout and its interactions. It can add a feeling of playfulness, speed and/or value to your project and help build a brand. It can also stand in the way of your users, make things sluggish, be confusing, or, even worse, promote harmful physical reactions: think of motion sickness and epilepsy (I'm no expert in either of those. If I mix things up, please leave a comment).
Like most things in UI, animation is a tool that needs to be wielded right and be applied for specific purposes.
Those purposes are:
- Provide information about possible interactions
- Make layout changes visible and comprehensible
- Emphasize spacial relations between your UI elements
- Improve the perceived responsiveness of the UI
- Create a recognizable brand
User Interactions need to give feedback. Let your users know if their action was successful. This can include visually depressing a button or changing the color of a link when it's active. There are simple examples that don't incorporate spatial changes in the layout and don't really need an animation.
However there are instances where an animation can provide useful feedback - For example an end-of-scroll animation like overscroll (Safari does that).
While smooth scrolling in itself is an animation that provides information about changing space, the overscroll effect proved additional information that the user has arrived at the end of the scrollable area.
You can also inform your users about a feature that's not obvious from a first glance. There's a slider on your page? Let it slide to the first position as soon as its initialized. This way you hint your users that there's more to see before they interact with it.
Some Elements turn it up to eleven and tell a full story about what's happening in the background, thus condensing a lot of information in a very small space. Animation shines here, because instead of explaining the process in words, you can simply show it. "Show, don't tell" is an important part of storytelling.
(Pen by Nerdmanship)
Suppose you have a grid of elements and a filter function to sort them by category. Your user opens the gallery and sees the first few pictures at a glance. At that point, they have a rough overview over the pages content. Now, they realize they actually want a specific subset of elements and apply a filter. The gallery will rearrange in the process.
If that happens instantly, the content of the individual images seems to change. It's hard to follow the changes and keep in mind, what images they already have scanned in their first glance.
However, when animating the rearrangement, it becomes clear where new pictures come into the viewport, making the change in state easier to process.
The official Isotope demo shows this pretty well:
(Pen by Dave DeSandro)
One of the basic design principles is about proximity: Elements that are near to one another, belong together. This is also applicable to animation. Have your animation establish relationships between your UI elements. As an easy example: Let your tooltips appear from and disappear into the direction of their trigger word.
(Pen by Chris Bracco)
A more advanced example: Let's have a series of cropped thumbnail images that trigger a fullscreen overlay each. You can just display the overlay, but then there'd be no information about to which thumbnail the fullscreen image belongs to.
Now let's fix it with a small transition from one state to another:
The overlay itself shows the user where it comes from, thus establishing a relationship between itself and its trigger. Not only provides that a feedback to what the user just did, it also provides a learning expierence. The user can expect a similar behavior on the next thumbnail.
With the thumbnail we reinforced an interaction that the user already triggered, but this also works the other way around. Let's hint them at the next step in the user story.
Our user is hungry and wants to order a pizza from our website. They configured their meal and are ready to put it in the cart and find out how to pay. Let's guide them:
This way we can playfully teach our users to effectively use the UI.
Perceived speed is a bit different from measured speed. Even though sometimes an animation slows down your UI from a mathematical perspective, they speed the actual usage up. This may sound counterintuitive, so let's clear things up.
The user may wait 200ms for an animation to finish, but only needs 50ms to process the visual change, resulting in 250ms to the next interaction.
Without any indication of a layout change the user doesn't wait for an animation to finish, but may need 350ms to adapt and understand the sudden change, resulting in not only a longer time to the next interaction, but also a more stressful one.
A study by Ericsson linked buffering times in streaming to an increased heart rate. We're not talking about streaming here, but stress by waiting is still real.
When your page loads a particularly heavy asset or slow API, be sure to let your user know that there's something going on. An animation has a clear advantage over a static loading screen, because it's moving. It tells your user that it's busy, working. Users tend to give up on loading times way faster when shown no or a static loading screen than an animated one.
Also be sure to convey as much information about what's to happen, as you can. Layout Skeletons (first below) seem to work very well, while spinners (second below) are still better than nothing (Source).
(Pen by Razvan Caliman)
(Pen by Aurer)
I've thrown around some numbers, so let's talk about time for a second (pun intened).
Lots of projects use one time value for all animations. Please don't do that. Instead, consider every animation on its own. Large movements take more time than tiny changes. It might look fine for a text color change to take 100ms, while the it's way too fast for an overlay to pop up. Worse yet, it might be perceived as an input lag instead of a transition, because the user simple doesnt register your animation as a proper motion.
Animations that indicate layout changes should take between 100 and 500ms, depending on their size. 100ms is perceived as almost instant. Go below that, and your users might not even notice your animation. Go above 500ms and you risk angering the user by making them watch the same lenghty animation over and over again. Keep in mind that your layout animation are propably played out repetitively. Go way above that to 1s and your users start to lose focus.
Cognitive science seems to have located a sweet spot at around 200ms. So my best guess would be to start there and just try out what feels best.
Very tightly tied to timing is easing. It describes the acceleration of an animation.
The simplest easing function would be linear, that means your animation starts and stops without any acceleration or braking. Because such motions have no origin in the real world. They feel very unnatural and mechanic, and quickly end up in the Uncanny Valley.
Most of the time, that's what you want to avoid. You'll be aiming for smooth, natural movements.
You can start fast and end slowly (ease out), do the opposite (ease in), both (ease in out) and everything in between. There's even a cool tool to help you create your own.
Acceleration and deceleration convey a sense of weight and inertia and imitates physical objects - things our brain is used to. They're less actively noticeable.
Like with timing, it's important to consider each individual animation instead of just creating one easing curve and applying it to everything.
Animated elements that react to a click feel snappier when easing out.
Elements that react to a cursor hover appear smoother when easing in and out.
That is because the user has a clear intention when clicking. It's an active input, as opposed to a hover.
Starting a hover-event is a more passive input and happens a lot more on 'accident'. Note that hovering out of an element is registers mostly as a more active interaction and may be better suited by an ease-out.
You can use the difference to let users explore features they didn't trigger yet (passive) and give feedback to events they already triggered (active).
Elements like links or buttons, that are expected to react immediately shouldn't wait for an animation to finish before they send user feedback, but might very well play one after being triggered.
(Pen by Max Caluva)
That's what you're here for, right? Bling, Eye Candy, Designer's vanity.
It's fun to make everything click together and create a seamless experience in your UI. What holds your transitions together is a consistency across not how they're made, but how they feel.
- Want to convey a sense of lightness and transparency? Try short animation times, and accentuated easing.
- A feeling of security and power? Try longer times, slacker easing curves and maybe less animations altogether.
- Playfulness? Try negative easing curves, so your animation goes cartoonlishly in the opposite direction to gather momentum, before firing off. Maybe consider a hero animation on top of your entry page. Or find odd shapes to create a signature element, like Smashing does with its user avatars and icons. This is where advice is kinda hard to give, since it's very specific to the case.
Modern browsers implement prefers-reduced-motion, which can tell your website if the user dislikes animations. This can have lots of reasons - from health problems, to screen limitations, to personal taste. If a user has a way of telling you that they don't wish to see your fancy animations, you don't show them. Respect their decision and provide a way of switching them off.
Lots of people nowadays sit in front of a large widescreen display or multi monitor setups, or completely concentrate on their phone screen while being in motion themselves. Those situations are incredibly hard to process for the human brain and can sometimes lead to motion sickness or other physical reactions. Animations that move elements which frame the center of attention may be perceived as messing with the physical space around the user.
While this doesn't always lead to motion sickness, it's always hard to process. This situation is actually comparable to sea sickness or what astronauts experience in zero gravity.
As a rule of thumb: The larger your animation gets, the more prone it becomes to inducing those reactions.
Please be mindful about that. If in doubt, find someone who is susceptible and test your layout with them. If still in doubt, tone it down a bit.
Content is king. If your animations are so obnoxious that your user has a hard time concentrating on the text, it misses its purpose. The same if it makes your content hard to read.
Always know where you want your users attention and then use animations to guide them there.
To do that, we'll have to be sneaky.
- We disguise our artificial, digital animations as natural movements (see the paragraph on easing).
- We keep them short and dense with information.
- We don't animate things we don't have to. Our animations have a clear origin (like a user interaction or a push notification) and a clear goal.
This is the keyword this whole article is coming down to. Ask yourself if an animation fulfills a purpose for the user. If it doesn't, it's probably purely aesthetic and therefore up for a second thought.
I'd like to compare purely aesthetic animation to code smells. They're not always bad news, but they raise a red flag. Where code smells provide a starting point to refactor, aesthetic animations provide a starting point to declutter your UI.
♿ A11y and Progressive Enhancement
It might be tempting to set an element to be invisible at first and then trigger a fancy fade in animation. Just consider what happens if your animation fails to load or is blocked by the user. Will the element stay invisible? Ideally, your animation will just be the icing on the cake. If it's missing, the cake won't be that tasty, but it'll still be a cake.
Do you convey information through an animation? Make sure to provide an alternative for screenreaders. Set your aria attributes. Keep cognitive and vision impairments in mind.
- Material Design is one of the best written design system. They have some extensive guidelines on motion: https://material.io/design/motion/#
- A nice article on functional animation: https://startupsventurecapital.com/your-ui-isn-t-a-disney-movie-703f7fbd24d2#.ls9jjs76l
- Decreasing perceived loading time: https://wp-rocket.me/blog/perceived-performance-need-optimize/
- A very in depth look at easing functions: https://www.smashingmagazine.com/2016/08/css-animations-motion-curves/