On animations

Mary Ng
Mary Ng
Feb 26, 2020 · 7 min read
Photo by Justin Lim on Unsplash

You’re going to be disappointed.

While I’m a huge fan of Disney and Pixar, this is going to be about web animations, not Toy Story. Although, I did choose this topic because I recently read the book Creativity, Inc., written by one of the co-founders of Pixar, which made me reflect a little on the kind of animations I have made in the past.

My first animation was fiddling around on Macromedia Flash back in high school. We had a project in our IPT class to build a website using Flash (*cough* this was more than 15 years ago) as a way to learn a bit on graphics design and ActionScript. As a 15/16 year old school girl, I of course built a fan site for a Japanese boy band whose name I no longer remember and each click that loaded different sections of the site would play a different background music.

I got a perfect score for that project and that’s when I knew I wanted to be a developer. I found out a few years later when I was in uni that the role that allowed me to play around more in this creative space was a front end developer.

Now, when we say “web animations,” the common meaning is one or a combination of HTML, CSS, JavaScript and SVG (scalable graphics). Gone are the days of Flash and GIFs, and to be honest, I don’t miss them. Flash in particular was not responsive, meaning it didn’t work well in different screen and device sizes. It also required a browser plugin in order to run and support for it was eventually dropped by popular devices, making it obsolete. But that’s alright, because we now have the technology that can tackle (most of) the problems that the predecessors presented.

Even today, when the project I’m working on is functional and it’s time to CSS it, I consider this the most exciting part of my job. The look and feel is an essential part to the user experience, but many don’t realise that the websites that do it well use animation to elevate it.

Most websites today have embraced animations on some level. Done properly, it will increase engagement with the users. Done poorly and it can cause unintentional distraction and confusion. In the worst case scenario, they may click that little ‘x’ button.

Functional animations

These are animations that are part of the UI design, carefully considered with logical purposes. They can:

I came across the best explanation on YouTube by my idol Sarah Drasner, who is, amongst many things, an amazing web animator (no, I don’t have a fan site). She explains what functional animations are by separating it into two different ideas.


Basically, the animation is not noticeable. This is the type of animation where the user shouldn’t be thinking, “Ooh, an animation just happened.” Instead, they should be presented with a cohesive and silent experience. When navigating through a website or app, the user starts to build up a mental map. This involves knowing the current states of the UI and what will be happening next. The smooth movement between the changing states are important because we want the users to have an intuitive and uninterrupted flow, and any jarring and unexpected interference can tear down that mental map they have built.

There are fairly obvious examples such as button and link hover effects. Also, transitioning colour changes, transparency, and so on. When devs and designers are crunching through work in a short amount of time, these transitional elements would be put in as an afterthought, rather than as part of the initial design phase and maybe missing the animation part entirely. Here are some examples as to why that’s not a good idea.

Input fields

The browsers’ native input label and field styles are accessible but boring. In order to apply your own design and branding to your forms, often the original styles have to be stripped back first but that removes a lot of the existing animations. You have to remember to apply it back and tweak it to meet your needs.

A common example is the humble toggle, which is really just a checkbox.

By wrapping the <input> inside a <label> element, they are bound together. This means we can keep all the default browser events associated with the input while hiding the input itself, as long as the label is visible. Within the label element, we can create our own toggle where the switch moves left to right when the input is checked.

By default, the switch in both examples is absolutely positioned left: 0; and when the input is checked, the position is now left: 35px;. The only animation, or transition, is applied to the switch in the left example: transition: 0.2s ease-in;. It is only one extra line in the CSS file and the effect is subtle, but the experience is quite different. Displaying a smooth transition of the switch inside the toggle provides the user with a subtle but useful feedback that the state has changed. The movement in the example on the right is harsh and the experience feels less polished.


Don’t you just hate it when a pop-up suddenly appears out of nowhere? I mean literally nowhere. I’ve been guilty of this in the past. Rushing to get a modal feature out the door into production, we often just make sure the content appears on the browser but how it shows up or disappears gets left out of the conversation.

The reason I feel this is important is because we need to give users time to adjust their eyes to the new focus area. Modals often take up a fair amount of real estate. Whether they were aware this modal was about to appear via their own actions (e.g. they clicked a button) or it was automatically displayed, it is a big change to the UI state. The context is also different. A gradual transition can help the user to adjust and focus on the new content.

Here’s a bad example:

And here’s how it can be improved:

In the latter example, the user now has context of where the new content is coming from. It’s a much more pleasant reveal, rather than a shock.


Everyone dreads seeing that spinning wheel of death. Not knowing how long you’re going to have to wait. Or whether the application just stopped working altogether and I’m just being naively patient. How long do you think it’ll take you before you just abandon it?

According to an experiment conducted by Viget, users are willing to wait longer when a carefully-designed loading animation is displayed compared to a generic loading wheel. This is most likely because users felt that their time was being valued (users can see that a more interesting loading animation translates to more time and consideration in the work). It also probably gives an impression of a smoother system with less flaws.

Experiments in Loading — How Long Will You Wait? | Viget


This is the attention-seeking kind of animation — but in a good way. The animation itself is the centre of attention because we are trying to draw user interaction with it. This can be a story-telling animation, a game, a tool for data visualisation, and many others. Flash used to be the tool of choice for this type of animation. Now there are many options like three.js and canvas, but I personally prefer SVG. As mentioned earlier, this is scalable vector graphics, so it works responsively, giving the user a crisp image on any screen size. I mostly choose SVGs because it relies less on my (lack of) illustrating skills but more on maths and co-ordinates.


“Animation can explain whatever the mind of man can conceive” — Walt Disney.


The Spaceship engineering, product and design blog