: What's the best way to animate an illustration for the web? I have a couple of illustrations done in Illustrator and I am planing to animate it for a website that I am working on, I've heard

@Miguel516

I did my bachelor project (graphic design) with this tool: tumult.com/ Just take a look on their website.

Vote Up Vote Down

@Murphy569

There are a lot of ways to animate things on the web. There are even more ways to create animations then export to web animations.

There are huge benefits to designing animations in something like AfterEffects or Animate CC (which can both import Illustrator and Photoshop files) for the obvious reasons of division of labor and use of a graphical editor.

With that being said, you should always, in the end, compile to one of the following:

Limited interaction capabilities:


GIF
Sprite
Video


More fully interactive:


Canvas
SVG
CSS
DOM based animation
WebGL


Now, I'll go into each in a little more detail.



GIF

A GIF is a good way to go when the animations don't require much interaction, doesn't need to be sized dynamically, and are relatively small. Well made GIFs can be as detailed as the illustration you linked without any performance worries. Even minor interaction using a transparent overlay placed over it (or just a part of it) is possible.

Side note: there is now a .gifv format created by Imgur which converts GIF files on the fly into the WebM or MP4 video formats. This increases performance by reducing the end file size greatly. You might consider doing the same.



Sprite

Another way to keep a smooth but highly styled animation is to use a sprite. Google uses this approach for things like logo animation. Another great example is Alexander Engzell's old website which had a sick typography animation using this approach. This is optimal when a GIF would be too large but you don't need much interaction.

I've also seen a very interesting JavaScript animation that resembles a sprite or GIF used by Google (hover the Chrome image in the top left - it requires being in Chrome) but uses an animated mask instead. I'm guessing they used this approach to limit the total file size.



Video

We've gained great capabilities regarding video in recent years. The <video> element let's us customize the way we interact and use videos like never before. Now we can make use of full-screen background videos easily and do things like go frame by frame on scroll. I also noticed that FaceBook uses video for some simple animations when welcoming users on their feed around special events. The benefits are that it can be compressed to a pretty small file size and can do a more wide range of animations (anything that video editing software can do). As such, if someone can make a sick video then it's fairly easy to turn that into a fantastic addition to a webpage.

Obviously, video's aren't good for the majority of animations on the web (e.g. button transitions, etc.), so don't use them everywhere.



With all this being said, if you want the animation to be dynamically generated, when you need more than really basic interaction, when you want to create 3D environments, and in many other cases, a GIF, sprite, or video simply won't cut it. Once this is decided, there are several other options, the best of which is dependent on your animation and needs.



Canvas

I don't have statistics, but most web animations I've seen use Canvas. Canvas is great to use because of its performance and flexibility in creation. It only uses one browser (DOM) element due to the fact that it just paints - like on a real canvas - things on top of each other. By keeping track of what's painted and where with JavaScript, we can create some pretty awesome animations and even games.

However, the primary drawback to using Canvas is its relative difficulty to scale. Often times, depending on the animation of course, it is more difficult to make a responsive Canvas animation than it is using other means. Another downside is that having much content on a Canvas is not very SEO friendly because canvas elements aren't crawlable (you can work around this by putting some visually hidden HTML of the content if applicable). On the same note, things like text selection for users is difficult with Canvas (especially without using a library like CreateJS).

A prime use of Canvas is Google's doodles, which are often done in Canvas. When they have a game or interactive animation, they use Canvas every time that I've looked. If there is no interaction, they'll use a GIF or sprite.

There are a lot of great libraries to help working with Canvas easier, though it's definitely not required depending on what needs to be done. Among the ones made just for Canvas are CreateJS (which you can export to from Animate CC), Pixi.js, PaperJS, KineticJS, and FabricJS (placed in order of my impression of them). An After Effects plugin named Bodymovin can also export to Canvas (or SVG[1]) and has a build in animation engine.

Of course, you can also pair larger animations libraries like GSAP with Canvas easily. For something as detailed as the illustration you linked I'd recommend using some type of framework, but for a lot of things they aren't really necessary, just useful - especially if you know how to use one of them already.



SVG

Another incredibly powerful way to animate things on the web in an easily responsive way is to use an SVG (Scalable Vector Graphics). They fulfill their purpose - being scalable vectors - well. Many find using SVGs confusing at first, but most things like SVG's coordinate system and transforms have great articles explaining them.

One of the many lovely things about SVG is that it can be animated with JavaScript, pure CSS (including :hover states, transforms, transitions, and animations), or SMIL animations (the "native" way to animate things with SVG - but IE doesn't support it at all and it's being gradually depreciated). I recommend trying to use CSS first and then JavaScript whenever it's not (relatively) simple in CSS. For morphing SVG elements, it's practically necessary to use a tool like GSAP's MorphSVG plugin unless you're okay with only partial support, in which case SMIL might be acceptable.

Since SVG elements can be in any shape, they can be used to create some cool effects. Sarah Drasner made some helpful performance benchmarks regarding SVG animations that show which ways of animating SVG is best performance wise.

Depending on the animation (and need of browser support), a library like Snap.svg or GSAP may be useful, but often times CSS and, if needed, a little custom JS is all that is required. With that being said, an After Effects plugin called Bodymovin and a Flash extension called Flash 2 SVG can be really helpful for creating SVG animations.

For more detail, take a look at this related post specifically on animating SVG elements.

P.S. It's best to use SVGs in an <object> tag or embedded directly in an <svg> XML element if it's interactive and as a background image if its not interactive, but there are other ways to do it as well.



CSS

In my experience, CSS animations and transitions should primarily be used for UI elements and other basic transitions and animations. Even then, sometimes using a JS animation library like GSAP or Velocity.js for UI animations/transitions is appropriate. It really depends on the type of behavior you want and whether or not it's convenient to do in CSS.

While we can create crazy things with pure CSS, it's generally harder to create intricate illustrations like the one you provide as an example using CSS, even when manipulating images in addition. Complex CSS animations are often times more difficult to maintain than their JavaScript counterparts as well. The other downside is that CSS animations are tough to change with JavaScript and it doesn't play too well when mixed with JavaScript.

With that being said, simple interactions using transitions and animations should usually use CSS; you should default to it. To start learning how to animate using CSS, check out my introduction to web animation.

You can also find helpful animations and easing functions in libraries like Animate.css that you can pull from and add to your own projects. You'll almost never need the whole library, take only the parts you want.



DOM based JavaScript animation

DOM based JavaScript animations are fairly straight forward. They have a bad rep because of terrible animation libraries like jQuery's animate(), but they can be particularly high performing, especially when using the web animations API (discussed below), or a specialized animation library like GSAP, Velocity.js, or mo.js (GSAP even has a special plugin to replace jQuery's .animate specifically). Using such a library, they can often outperform other types of animations for more intensive animations, such as animating a whole lot of elements.

The main reason why you'd need to use a DOM based animation is if you have a lot of user animation or complex timelines involving already-made DOM elements. Often times it's best to try and use something like Canvas over the DOM for reasons already specified.

Libraries like GSAP let us do crazy things like slow an animation on hover by keeping track of the animation matrices. In this way, DOM based animations can be more customized and interactive than any other form of animating when done well. The only down side is that sometimes, depending on how it's built and what it needs to do, it won't perform well.



WebGL

WebGL is a way to create primarily 3D works. It has some awesome projects that you should check out. It's not to be used on every web page, obviously, but it's important to mention.

It actually animates DOM elements to create 3D (and 2D) environments which is awesome because of the potential it has. When using a library, WebGL falls back to using Canvas but still doesn't have great support on mobile and can be performance heavy. Generally it's pretty clear when you need to use WebGL or not.

From my experience, using a WebGL library is practically necessary. Thankfully there are some good ones. ThreeJS is by far the most common I've seen followed by PixiJS. A WebGL framework like A-Frame can also make picking it up and creating basic things pretty easy.



A note on the Web Animations API (WAAPI)

The web animations API is an attempt to standardize how animations are implemented and maintained across browsers paired with performance improvements. It is meant to be used with DOM elements including SVG. It resembles how a CSS animations is structured (in a JS looking form) but adds capabilities such as a timeline and improved performance.

It improves performance by putting animations on the compositor thread (for more details check out this great post on the subject). For an introduction to how to use it, check out the Mozilla docs or this introductory post.

You may ask, "Will this replace JavaScript animation libraries?" The answer is "Hopefully some". It's beneficial for everyone for the native browser animation engines to improve and, as they do, some less powerful animation libraries will become useless. With that being said, more powerful animations libraries will still have additional benefits like the ones GSAP noted. Whether or not you need a library once WAAPI is widely supported is still determined by yours needs.

WAAPI currently doesn't have good support but can be used with a polyfill in production today. It looks like it'll continue to get better and get more support.



Some notes on performance


Avoid using non-performant properties or causing reflows/repaints.
Avoid animating a bunch of elements on the page as they are more intensive and can also be a pain to change later on.
When using CSS, use a transition over an animation whenever possible (within reason). They perform better and are generally easier to work with.
Intelligently use the will-change property on large elements that you're going to animate so the browser knows ahead of time. For more details and suggestions about it read something like this SitePoint article on the subject.
Avoid setInterval and opt for requestAnimationFrame when doing timings in JavaScript (good animation libraries like GSAP do this for you if you use their timelines).
When you can, use the web animations API because it has capabilities for animating with other methods in JavaScript don't have.




A note on Flash

You should never run Flash in the final product. JavaScript animations perform better, are more dynamic, are more easily edited, don't require any downloads, work across more platforms (Flash doesn't work on most tablets/phones), and are more responsive than bulky old Flash ones. They also aren't very accessible and are not SEO friendly.

With that being said, Animate CC (a rebranding of Flash) is a useful way to create animations and can export to Canvas using Create.js.



In conclusion

There are usually multiple methods you can use to create an animation. The best one depends on what you want it to do, and sometimes there isn't a clear better method. Often times I find myself using multiple on the same project. The important thing is to think critically, to understand exactly how you want the animation to behave, and to decide on the method based on that. It also helps if you've worked in each a bit.




[1] - Bodymovin can also export to native Android, iOS, and React Native.

Vote Up Vote Down

@Rambettina927

In my experience, when doing static animations (animations that are not intended for any interaction with the user) I found that what best worked for me was animating the illustrations in After Effects and after that exporting the final result to a .GIF file. This makes the animation absolutely browser-friendly and guarantees identical visualisation in any device.

If, however, you are looking for something that a user might interact with, I believe Canvas is indeed the way to go, and for that CreateJS does seem to be right for the job with the EaseJS library.

Anyway, according to your example, you could just as well do it with an animated GIF file and get the exact same result.

Vote Up Vote Down