Introduction to Animation

Animation is change over time.

Traditionally this was done by creating still images and displaying them one at a time at a high enough speed to create the illusion of smooth motion - picture a flip book. This type of "frame by frame" animation, though tedious to create, still has many uses today: stop motion animation, hand-drawn cartoons, and even some computer animation techniques still use this simple method. Animation playback speed is a function of the number of frames times the frame rate, measured in frames per second (FPS). The higher the frame rate, the more capability there is to display motion smoothly. For most purposes we can aim for a frame rate of 30fps, though the human eye can detect much higher on very dynamic scenes with fast motion. Higher frame rates come at the cost of more visual information to create, transfer, and render, and face limitations with display hardware as well.

A more advanced method of animation beyond frame by frame is "tweened" or "keyframe" animation. The term "tween" came about when you'd have a lead animator drawing the major "key" frames at large intervals or when something important changes, and then an army of subordinates doing the "in-between" frames; "tween" being shorthand for "in-between". When applied to computer animation, we have the computer handle the "tweening".

Animation for tv, film, and video is authored, rendered, and output to a static video file that can be played back. In the early days of the web we needed plugins to display video, now HTML5 video standards are universally supported by modern browsers and devices.

Animation on the web adds many more possibilities in how it can be authored, rendered, and experienced.

On the authoring side, you have the ability to utilize all traditional and video animation techniques as well as an endless array of programmatic methods unique to the "front-end" languages of the web, namely: HTML, CSS, and JavaScript.

On the rendering aspect, animation on the web allows for "client-side" rendering by the user's web browser and device hardware. This means that animation does not have to be rendered ahead of time, but rather is generated on the fly. This also means that it can potentially respond to changes on the fly, if authored to do so: user interactivity can be integrated, responsive screen sizes can be accounted for, other non-user factors such as live data feeds or camera inputs can be accessed in real-time; the possibilities are limitless. There are limitations to client-side rendering, however: large file sizes for assets versus bandwidth can become an issue, processor power and memory can be issues especially on mobile devices or older systems, and differences in screen sizes and support for granular features can create complications in attempting to deliver the same experience to all users.

Why use animation?

Because we can. Because it's cool. Because it sets those who do apart from the masses that don't. Because it pushes the boundaries of web technology and hardware, allowing designers and developers to deliver new experiences to users. Animation, especially when paired with interactivity, can breathe life into something otherwise visually static and transform it into something playful, more immersive, arousing curiosity in the user to spend more time exploring content and engaging with it at a deeper level. Animation can add emphasis to important user interface elements and content, create a path leading the user's experience in specific directions. Animation is attention-grabbing, and it should be used with careful consideration, however. It would be easy to create something so overwhelming and confusing to the senses that it's a detriment to the experience.

Potential uses of animation on the web

Design considerations

Designing for the web can be a pretty difficult task, especially since responsive design practices require that the same user interface and content be adaptable for all users on all screen sizes on all devices. Now lets throw in some new technologies, complex interactivity, and the element of time! Designers aren't always animators, animators aren't always designers, and creating animation on the web may fall to a developer who is neither a designer or animator; these are all reasons that animation on the web is underutilized. Since there are special considerations and often a lot of effort involved with web animation projects, collaboration is especially important.

There's also a misconception that "animation can't work on mobile" that isn't necessarily true, and offering an amazing desktop web experience and a minimally similar dumbed down version for mobile can do a disservice to the content and brand you're trying so hard to help stand out on desktop. Mobile devices have limitations with screen size, with ability to process complex animation in some methods, and the ability to handle scroll position-based JavaScript, but there's a lot they still can do.

These are CSS properties that are often animated, for example: width, height, scale, rotation, placement, opacity, color.
These are interactive events at which things can be triggered to happen, for example: responsive screen width, height, and/or aspect ratio; scroll position on the page as measured from the top or bottom, from other elements, when other elements are in or out of the viewport; mouse hover (which is desktop only) or click/tap; drag, drag and drop; keyboard keys; any event can set or stop a timer; external events such as time or triggers from other sites and data sources; conditional logic such as do this then this happens; mobile devices have gyroscopic sensors; GPS or IP-based geolocation.. the list is virtually endless.

Development Considerations

Animation often means working with new technologies in new ways, which is something most developers do all the time, but especially so in this case since very few developers have the opportunity to be full-time web animators. Since animation involves the element of time, mistakes and misdirection can lead to lengthy revisions.

Since nearly all animation techniques can result in crippling performance in the browser if done poorly, development requires careful attention to performance beyond function, in all aspects of the UI – HTML, CSS, images, and especially JavaScript functionality. Ensure that HTML structure is valid to reduce browser clean up operations, minimize excess DOM nodes to speed up rendering and DOM manipulating JavaScript, keep CSS efficient and minimized. Learn what operations trigger a "repaint" in the browser when changed (for example, it's more efficient to change a CSS3 transform property than it is to change width/height, margins, or top/right/bottom/left positioning.)

Most importantly, evaluate all JavaScript used on the site - use efficient DOM selectors, make sure any scroll-position or resize listeners are throttled or turned off if not needed. Keep large libraries and possible performance conflicts down to a minimum. Many of these recommendations are simply not possible in some CMS-based environments, especially those that produce excessively complicated HTML structure and automatically include include a number of performance-intensive JavaScript operations, and thus there may be limitations you wouldn't hit in a more minimal environment where you have more control over the code.

Because of the performance limitations and cutting-edge support required for some animation techniques, it's very important to vet any animation solutions at the outset, and to test frequently and thoroughly in desired browsers and mobile devices. Compared to a "standard" web site, you'll frequently run into more browser bugs that have to be worked around, performance differences between platforms, and spend more time ensuring everything works flawlessly on projects involving animation. All modern browser dev consoles/inspectors now have powerful tools to help you find and solve performance issues: inspect memory usage, take processor performance snapshots, let you inspect visual rendering / painting. When rendering performance on mobile is concerned, it is especially important to test on actual devices, or to use a service that does that virtually. I've found the most issues with bugs and rendering glitches in Safari and on iOS mobile devices, personally. Though recent iOS hardware and OS' support scroll position-based JavaScript events better than Android does. Traditionally, mobile devices disable JavaScript on scrolling, and event listeners fire after scrolling stopped.


Project Considerations

Depending on what's called for in the wide world of web animation, these projects can be a handful. Animation concepts may be difficult to design, to relay to clients in any draft form, interactivity considerations can be tricky to plan out, developers may be dealing with new technologies and lots of unknowns, any changes down the line can be very time consuming, testing can take longer, and bugs can be more likely and more difficult to solve. In short, animation is more likely to involve risk. Minimizing risk involves careful planning and estimating, collaboration, and possibly some padding on the timeline and budget.


Native CSS3 and JavaScript APIs = Good performance, native to modern browsers

JavaScript Libraries = If you can code, you can animate; using simple methods and superpowered frameworks.

Adobe Animate (formerly known as Flash)

There really aren't many powerful "web animation software" products other than Adobe Animate. With the death of Flash technologies due to security risks, Adobe's proprietary plugin approach vs Apple's proprietary hardware and software approach at an impass, and HTML5 catching up in capabilities, Adobe rebranded Flash as "Animate". (Not to be confused with their short-lived DOM animation software called "Edge Animate", RIP). Animate fully integrates the 3rd party CreateJS HTML5 canvas animation library into the formerly Flash software interface. With the appropriate knowledge of the software, this allows for extremely quick animation prototyping and production, with visual layers, keyframes, and tweens, and many special features and tools to speed things up. Since the output is HTML5 canvas and JavaScript-driven, it can also interface with external JavaScript. Animate also can output to video and SVG, which can be useful when delivering different versions of the same animated content for different purposes.


General References: