A Change in Motion

Working with vector-based animations

Avatar

Juan Flores Mena

Product Design & Prototyping
@72mena

Numbers used in Google IO 2016 countdown

This analysis was picked and published by the Framer team on their Medium blog back in 2017. This is a revised version.

I have always advocated for using code as a tool for design exploration.

But at the same time, whenever I’m in a team that’s trying to adopt code in their design process, I identify the designers that are not on board with it. Not all of them speak it out loud for fear of being judged, but I try to stand up for them and their right to not use code.

This may sound contradictory — as I don’t share their point of view — but it’s important to respect their choice and to understand where they’re coming from. A good alternative is to help them improve their design process in a different way.

This article is about that: a case in which code may actually limit designers instead of empowering them. And an alternative that I consider will become a game changer.

This is about working with SVG Animations.

Why SVGs?

SVG file icon

SVGs are crucial. If you’re working on an app and want to include complex animations, you can’t just throw a bunch of animated gifs and videos if you want to have a lightweight application.

And SVGs are super lightweight. You don’t have to worry about assets for different resolution screens, the vector data scales extremely well. And on top of that you can animate them — through a painful process, but you can do it.

SVG Animations

A brief summary of my personal experience learning about SVGs.

Google IO 2016

Last year I was intrigued by Google I/O’s countdown, it was a really cool animation that was not a video nor a gif, but it was created with code. I tried to ask for a tutorial on how to make something like it.

Loop of Number

There were no responses. No luck. I knew it was an SVG Animation, but I just didn’t know where to start if I wanted to create something like it.

So I decided to get into SVGs. I read articles and tutorials and became a big fan of the work created and shared by Sarah Drasner and Sara Soueidan. I recommend you to follow them on Twitter and read their articles. You will learn a lot from them.

I also started to learn the caveats of this technology (like SMIL animations) and the common workarounds and best practices to animate SVGs.

After learning the basics, I found GreenSock and their GSAP (GreenSock Animation Platform). I gave it a chance and, after some experimentation, I managed to put together my own Google I/O countdown.

I was happy with the result, specially considering I had to connect the dots by myself. But here’s my take on this experience: It was not fun.

Working with code can be painful at first, there’s nothing new about that. I’ve had my fair share of going through learning new languages, and I plan on continuing doing so — it’s a very rewarding feeling when you finally make it work.

However, working specifically with SVG Animations was different for me, there was not a lot of flexibility to iterate and experiment freely.

The main issue I identified was that much of the techniques and workarounds that you learn about are either experimental (meaning, not supported by all browsers yet) or obsolete (deprecated by most browsers).

And I’m aware that you could say something similar about JavaScript, and I do enjoy working with JavaScript. But we’re talking about coding animations here.

Although I find SVG Animations to be very interesting, and I plan on continuing learning more about this field, I know I’d have a hard time advocating for it and bringing other designers on board. That’s what’s important here: finding alternatives.

A game changer: Bodymovin

JSON file icon

As I mentioned before: if designers in the team do not want to dive deeply into code, I try to find alternatives to help them extend their set of design tools so we can empower their process in different ways.

I knew it was going to be a hard sell to persuade other designers to work with SVG Animations. And I recently found what I consider to be a game changer: Bodymovin.

Bodymovin is an After Effects plugin created by Hernan Torrisi. It’s a free plugin and you can follow the project on GitHub. (This project is not new, but it’s not mentioned or shared enough.)

A good way to explain what this plugin does is to compare these two setups:

Illustration of SVG code

Normal Setup of SVG Animations

Today’s workflow to create SVG Animations on the web is to draw the SVG in the DOM, and then to animate it with CSS and JS. This means that every animated element — and their concept of timing and timeline— needs to be handled with code.

Illustration of AfterEffects

The Alternative Setup with Bodymovin

If we think about After Effects, we think about a tool that will let us export our animations as movie files or animated gifs — and as I mentioned earlier, ideally we shouldn’t include a bunch of these files in our apps.

However, with Bodymovin, you can work on a vector-based animation in After Effects and then export it as a JSON file. This is HUGE.

Animating for the Web and Native Apps

A consistent result across platforms

Lottie Logo

Animating SVGs presents different challenges depending on the platform you want to run them on. The techniques that you learn to animate SVGs for the web won’t let you just jump into animating SVGs for iOS or Android.

A common challenge in Product Design is to keep one same vision from Design to Development — and to have a consistent result across platforms. This is why when it comes to complex animations, teams will either simply use a video, an animated gif, or downgrade it to a nice-to-have in the project scope.

But here Bodymovin has also made an impact. Bodymovin inspired Facebook’s Keyframes and AirBnb’s Lottie.

Both platforms are doing great things but Lottie is a bit ahead of the curve here (v2 is available on Android and v1.5 on iOS as of this writing).

AE JSON Lottie Logo

Lottie will let you use the same lightweight JSON file exported from After Effects to run your animations on Android and iOS.

One animation. One JSON file. One consistent result across platforms.

(If you talk about Lottie, don’t forget to mention and thank Hernan Torrisi for creating Bodymovin and making it available for free.)

A prototyping combo: Bodymovin + Framer

Animations meet high-fidelity fast-prototyping

Framer Logo

Framer is the tool I use the most to explore new designs and interactions. It’s a crucial part of my workflow, and I thought it would be very helpful to be able to use the animations exported with Bodymovin in my prototypes.

Just think about it: If you’re designing a mobile app, you could be using in your prototype the same JSON file that would be included in the iOS and Android builds.

I created a module for this and used the same Framer flavor we all know and love. Just import the module, create a (bodymovin) Layer and play with its attributes.

Code Example

That’s it! That’s all it takes to have a vector-based animation running in your prototype. And again: you’d be using the same JSON file that would be delivered to the development team to implement it on iOS or Android.

If you compare this setup with the complex one you’d need to create to run SVG Animations you’ll understand why I consider Bodymovin to be a game changer. A designer can focus on using code for prototyping and AfterEffects for complex animations — instead of having the constraints of coding animations for the DOM.

I also surfaced other attributes you get from Bodymovin:

Code Example 2
  • ‘loop’ takes a boolean (true or false) or a number. ie. if you pass a 3, it would only loop the animation 3 times.
  • ‘speed’ is 1 by default, which is normal speed. 2 is double the speed, 0.5 is half the speed, and so on.
  • ‘direction’ is 1 by default, if you set it to -1 it will play the animation backwards.

Each attribute is quite self-explanatory, but you can see the documentation in the GitHub repo. There are also methods you can use to control your animation, like play(), pause(), goToAndStop(), etc.

Here’s the GitHub repo to the module

And a demo of a Framer prototype with JSON animations

Keep in mind that this is not only for simple animations like a hamburger menu morphing into a back button — btw, a “simple” animation like that one, as mentioned by Gabriel Peal in episode 82 of the Fragmented Podcast, took him days to develop it for Android.

This is about complex vector-based animations like this one:

Animation Loop

Here I had to use an animated GIF. But that’s actually good because we can use it as an example:

  • This GIF is 742Kb. I had to reduce its quality a lot, and its dimensions are a mere 550 x 380px.
  • The animation as a JSON file is 167Kb. And it’s super sharp because vectors… which means that it can also be scaled to any dimension without affecting its quality or the file size!
  • The SVG Animation doesn’t exist. It can be done, sure, but it would be much more complicated. And remember that another challenge would be to recreate it for different platforms, not just for the web, and have a consistent result across them.
  • To view more JSON animations like this one created by Joris van Raaij, check LottieFiles.

Summary

  • SVG Animations are complicated! Learn about them, and help non-code oriented people in your team find alternatives if needed.
  • Bodymovin is a free plugin for After Effects to export vector-based animations as JSON files. (Thanks Hernan Torrisi)
  • Bodymovin’s JSON files are super lightweight. Sometimes an entire animation is even smaller than one frame of it as PNG.
  • Use Lottie to run these JSON files on Android and iOS. (Thanks AirBnb)
  • If you use Framer, I created a module that lets you run these animations in your prototypes. And here’s a demo.

Please note, this post wasn’t titled “SVG Animations Are Dead, Now What?” or “Why I Stopped Using SVG Animations and You Should Too”, that’s not where this is coming from. I’m curious to know more about other workflows, please share yours, specially if you have experience launching complex animations across different platforms.

72