Issues

Responsible Animations for the Web

Photo of Mike Masey
Author Mike Masey
Published Issue No 46   •  
Read Time

Back in November last year I did a talk at the Umbraco UK fest about Responsible Animations, and the wonderful folks at Skrift has asked if I could put together a follow up article, which works out great for me because I’ve already started making some modifications on how to explain what Responsible Animations are.

The idea behind Responsible Animations is to hopefully get developers, designers and agencies as a whole thinking about animations in a more holistic way.

So let’s start at the beginning. My introduction to programming comes from the frontend world of the web, It’s only been in the last 4 years or so that i’ve started delving into the backend (namely with Umbraco). As a result i tend to view myself as a frontend developer first, with enough backend chops to see me through. My day to day can switch from pure frontend to pure backend and somewhere in between and recently i’ve found myself focusing on improving animations. After reading through countless helpful articles (some of which I will include below) I found that many of them cover similar point but as a whole they were falling under what I’m going to be calling Responsible Animations.

What does it mean

The idea behind Responsible Animations is to hopefully get developers, designers and agencies as a whole thinking about animations in a more holistic way. I’m going to do this by splitting it up into a few separate parts. I’m not going to tell you what your animations should look like and i’m not going to dive to deep into each section as I want to leave you thinking about each section as a whole.

The best animations are the ones that have a purpose. They don’t hang around for ages showing off, they don’t try to get all up in your face. No, instead they’re short, potentially have a functional use case and of course still delight. A few examples of functional animations include:

  • Providing visual feedback for button interactions

  • Improving an onboarding experience to indicate how a process works

  • Indicating system status, e.g. a pull to refresh animation

  • Making state changes feel more natural

So the first part of a responsible animations to the think about what it is going to add to your project. If you find that you’re adding animations just for the sake of it, take a step back and see if you can use them to your advantage. Maybe you can draw focus to a call to action or highlight something new. This isn’t to say that having an animation that’s simply enjoyable to see isn’t allowed, but the more useful you can make them the better.

There is a lot of great information regarding functional animations out there, some of which include:

Accessibility is an incredibly important part of the web. The for most part it should be seen as a requirement, not a feature, and it’s reach extends into the world of animation. As we’re dealing with movement there are a few things that should be considered when creating a Responsible Animation.

Vestibular Disorders

A vestibular disorder refers to an issue with the vestibular nerve in the inner ear. It can cause dizziness as well as disrupt your sense of balance. According to vestibular.org, it effects as many as 35% of adults over 40 in the USA (https://vestibular.org/understanding-vestibular-disorder).

If a person suffering with a vestibular disorder visits a site with a high frequency of animations, it can essentially make them feel sick. It’s not just people with permanent disorders either, If you’ve ever had a ear infection or even just had a bad bout of flu, you’ll know how rough seeing over the top animations can make you feel.

So what can we do to make sure our animations don’t make people feel sick. A few simple rules include

  • Keep animations short. Most of the time, between 200 and 500 ms should be enough time to achieve an good interaction animation.

  • If your animations take over 5 seconds, provide an option to pause it

  • Parallax animations are a big culprit for triggering dizziness, nausea or vertigo. If you’re using those type of animations, either provide a way to turn them off or make the movement minimal. If in doubt, test.

You can also make use of the "prefers-reduced-motion" media query to remove or reduce animations. It’s a feature at the time of writing only supported in Safari and Firefox, but it allows people to turn of animations at the system level. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-motion

Reducing Cognitive load & improving UX

Animations can be a great tool for reducing cognitive load and guiding a person through and experience. Keep this in mind when designing your animations, thinking back to why you are including them, and how they could improve the usability of your website or app.

This is a great article to get you started on a closer look at accessible animations

Performance like accessibility covers a vast swath of areas from backend server response time, to the smoothness of an animation. We’re going to be looking at the latter. The subject of performance is huge and sometimes overwhelming so bear in mind this is only a small part of what you should consider. I’ll link to some great resources on performance later on.

There are a multitude of aspects that can affect the performance of animations on the web. How powerful a person's device or computer is, what browser they are using, what specifically is being animated and so on. Part of creating a responsible animation is ensuring whenever possible that your animations are running as smooth as possible, without any stuttering, often referred to as "jank".

Ensuring that you achieve jank-free animations requires keeping in mind a number of variables. Let’s being with a number.

16ms

That’s the amount of time it should take for your website to render a frame from start to finish. Luckily for us, computers are great at working quickly, but we still need to make sure we’re doing things in a way that doesn’t get overbearing on our browsers or devices.

We have our time we need to work in, but what actually needs to happen in that time.

Each frame begins with JavaScript. All your requestionAnimationFrame logic, adding or removing DOM elements, your CSS based transitions or animations and more happens here first.

Then the style calculation are worked out, which means the browser figures out what styles to apply to each element.

The browser then has to figure out how much space each element shout take up on the page. Each element can affect many others, for example changing the width of the body may affect the width of each child element.

Once the layout step has completes, the paint process begins. This is where all the pixels are calculated for the page. This is often done onto multiple layers.

Finally we have the composite phase, which orders each of the elements correctly to make sure there aren’t odd overlap issues. The composite thread is also slightly unique in that it runs on the GPU instead of the main thread. This can have boths pros and cons.

Each part of the rendering phase can introduce performance issues so be mindful of how you are composing your animations. Are you increasing the size of an element as part of a hoverstate? If you’re changing the width and height property, you’ll trigger what is know as a "reflow" or “repaint”, this means that each part of the rendering process will have to complete. If you change a transform property instead, you’ll actually skip the layout and paint step (depending on the browser) meaning the animation should run smoother.

If you want to see how different properties affect the render, check out https://csstriggers.com

I would highly recommend learning how the rendering process works if you want to learn how to improve the performance of your animations. Most browsers tend to have a way for monitoring the performance of a page via the dev tools. In the Google DevTools for example, we can view what different phases of the render occur and how long they take which is incredibly useful when you’re trying to identify any issues.

In my talk i mentioned a little bit about the Web Animations API. I’ve decided not to go into it this time as although it is important and will hopefully be a useful feature to take advantage of, i didn’t want to take away from the main message. If you want to read up some more on performance here are are few articles that have been very useful to me. Be prepared to fall down the rabbit hole.

Being time effective with animations actually covers two areas. The first is one we’ve already covers slightly, which is to do with how long you animations should take to complete. As mentioned in the accessibility section, shorter tends to be better.

The other part that hasn’t been mentioned impacts the whole team working on the project. I’ve already told you that the functionality of an animation should be thought about, but that’s not to day an animation can’t be there to simply add some delight to an experience. With all the use cases in mind you should also think about how long they will take to implement. Can you build them in a way they they can be reused efficiently. As developers the concept of DRY (don’t repeat yourself) is often a familiar idea, can you translate it into your animations so that you don’t end up using half of your development budget getting the right swipe animations on your page transitions. As a whole, adding animations shouldn’t come at a detriment to your development time. Depending on the type of project this may not be relevant, but I think it’s good to keep it in mind.

This brings me to my final part of Responsible Animations. Initially i didn’t include this as a core part as it encapsulated all of the previous ones, but i think it’s important enough to highlight. How often do you get towards the end of a project and there’s a bit of time left and your told, let use it to add some nice animations. Now this can be fine, and sometimes time constraints or budget can lead to this. But whenever possible, try to plan you animations before you even start writing your code. Collaborate with your team, from designers to project managers. Thinking about your animations up front makes it much easier to consider how to build them in a time efficient way. It lets you think about any accessibility issues that they may create, and you can start thinking about how to ensure they are performant. Your designer may not know what sort of animations work well for the web for example. If you work together, you can reach a result that works for everyone, with a much higher chance of it being completed, rather than sticking it on at the end if you have enough time.

Planning your animations also means you can show off to your client how impressive their site could look, which may help you to build in more budget to cover some animations that wouldn’t have been possible before.

It can be difficult to communicate animation ideas, but it can be as simple as sketching a small storyboard for a page transition, to using something like principle http://principleformac.com/.

Another part of planning your animations can be discovering that you shouldn’t be including them in the first place. If it feels like you’re adding animations for the sake of it, maybe take a step back and think, is this really necessary. Is it adding value? Could it take up to much dev time? Sometimes the best approach can be to not include them at all.

Summary

  • Planning
  • Functionality
  • Accessibility
  • Performance
  • Time effective

If you can keep these in mind when creating your animations, hopefully you will have a brilliant Responsible Animation that will stand out amongst the others. I don’t have much more to say in terms of a summary other than I hope you have found this useful. If you have please share the concept amongst your peers. If you have any questions feel free to reach out.

Become a Patron!
comments powered by Disqus