Web Animation Past, Present, and Future

Web animation has been exploding during the past year or two—and the explosion has been nothing short of breathtaking. JavaScript animation libraries like GreenSock have become the weapon of choice among interaction developers, and web design galleries like Awwwards and CSS Design Awards abound with sites reminiscent of the Flash era. It seems like every front-end development conference includes a talk about web animation. Last year at motion design conference Blend, Justin Cone of Motionographer called web animation the future.

Things are moving fast. So let’s recap.

Web Animations API coverage increasing#section2

The Web Animations API is a spec created to unite CSS Animations, Transitions, and SMIL (native SVG animation) under one animation engine. JavaScript developers can tap into it to build more performant DOM animations and libraries. Browsers can also tap into the API to build more advanced animation developer tools—and they’ve been doing just that.

With solid support from Firefox and Chrome teams, the Edge team moved the Web Animations API from “under consideration” to “medium priority,” clearly a reaction to the web development community’s votes for the API via Edge’s User Voice campaign. And let’s not forget WebKit—a team at Canon might be taking up the Web Animation banner! Could this mean WAAPI in iOS Safari? Find out in 2016! Or 2017.

SMIL falls as SVG rises#section3

Ironically, just as Edge moved to support the Web Animations API (a prerequisite to Microsoft’s adoption of SMIL), Chrome announced it would be retiring SMIL! Even without SMIL, SVG remains synonymous with web animation. That said, due to varying implementations of the SVG spec, animating it reliably across browsers is often made easier with third-party JavaScript libraries like SnapSVG or GreenSock’s GSAP, a tweening library for Flash that was rewritten in JavaScript.

Fortunately, some of the bugs that got in the way of animating SVG components with CSS have been addressed, so library-independent SVG animation should become more common in the future. Down the line, we can expect SVG behavior to be normalized across more and more browsers, but because of its unreliable reputation, developers will probably continue to associate SVG animation with GSAP and use it regardless.

In this regard, GSAP might become the next jQuery as SVG behavior normalizes and browsers expand their native abilities to match developer needs. That is to say, GSAP will remain the tool of choice for ambitious, complex, and/or backward-compatible projects, but could also suffer a reputation blow if it starts to look like a crutch for inexperienced or out-of-touch developers.

Prototyping solutions fall short#section4

One of the greatest challenges facing web animation has been tooling. Animating the web today requires years of accumulated CSS and JavaScript knowledge to accomplish things that seem primitive in comparison to what a designer with Adobe After Effects can learn to do in a month. This means that either front-end developers become animators, or designers become coders. (Could animation be the thing that unites these two at long last?)

Various tools and frameworks have emerged to try to meet this need. Frameworks like the aptly named Framer create “throwaway code” you can test with users; to work with it requires a basic knowledge of web development. Some apps, like Adobe After Effects, provide critical animation tooling (like a timeline UI) but only export videos, which makes iteration fast but user-testing impossible. Others, like InVision and much-lauded newcomer Principle, fall somewhere in between, providing a graphical interface that produces interactable prototypes without actually creating HTML in the process.

All of them have their pros and cons. For instance, the animation workflow may be right, but the web development workflow ends up wrong (and vice versa). This leaves an opening for differentiation. Animation tooling might be the winning feature during upcoming jostling for market share in this crowded arena.

But right now, none is a clear winner. And some are already losing.

The framework Famo.us once touted its 3D physics animation engine and excellent performance to prototypers and ad designers. In 2015, it pivoted abruptly out of the space. Similarly, Adobe retired its web animation racehorse, Edge Animate while rebranding Flash Animate CC. Flash will continue to export to WebGL and SVG, but the message seems clear: Flash’s future looks more cinematic than interactive.

Browser tooling improves#section5

In December of 2014, Matt DesLauriers wrote, “I also feel the future of these tools does not lie in the document.body or in a native application, but in between, as part of the browser’s dev tools.”

The Web Animations API’s increased adoption allowed Chrome Canary and Firefox Developer Edition (disclaimer: I helped build the demo site) to launch their own animation tools in 2015. In the future, we can hope to see these tools grow and change to accommodate the web animator’s process. Maybe even as the Web Animations API becomes more well known, we will see third-party tooling options for CSS and SVG animation editing.

Motion guidelines adoption up#section6

Following the lead of Google’s Material Design system, IBM and Salesforce released their own design systems with motion guidelines. (Disclosure: I assisted Salesforce with the motion portion of their Lightning Design System.) Increasingly, large companies that can afford to spend more time finessing their design systems and branding have been investing in codifying their UI animations alongside microinteraction guidelines. We’ll most likely see more medium-to-large companies following in the example of these giants.

How that documentation plays out largely depends on the audience. Persuasive and beautiful documentation of animation theory prevails at large companies recruiting internal animation evangelists, but when the product is designed for mix-and-match developers, animation rules become stricter and more codified alongside best practices and code.

UX and accessibility#section7

We learned a lot in 2015 about vestibular disorders (I even did a special screencast on the topic with Greg Tarnoff), a concern that may be wholly new to the web development community. Unlike contrast and ARIA roles, which can be “accessible by default,” the only animations that are accessible to everyone by default are opacity-based.

For those not willing to abandon animation or convert to an entirely fade-based UI, the challenge we face is how to give users choice in how to experience our sites. I’ve already written about our options going forward, and we are starting to see a proliferation of “reduce motion/turn animation off” UI experimentation ranging from discreet toggles to preference panels. Like the “mute audio” option, one or two of these will likely rise to the top in a few years as the most efficient and widely recognized.

As more edge cases reveal themselves, UX and accessibility concerns will deepen. If left unaddressed, the company’s front end will carry extra technical debt forward to be addressed “another day.”

Animation matters#section8

Since animation’s return to the web development and design toolkit, we’ve been using it to tell stories and entertain; to increase the perceived speed of interactions; to further brand ourselves and our products; and to improve our users’ experiences. And we’re just getting started. New specs like scroll snap and motion paths build upon the foundation of web animation. New tools and libraries are coming out every day to help us further enrich the sites we create. And more and more job postings request familiarity with CSS animations and libraries like GSAP.

As the field of web animation expands, it will be abused. The next parallax is always just around the corner; as new and unusual trends proliferate, clients and managers will want to see them reflected in their sites. Hopefully we learned something in those years without Flash; good design is about more than chasing after trends and trying to impress each other or a segment of our audience. We learned that building terrific web experiences means listening to users as well as pushing the web forward. And if we listen, we’ll hear when the bouncy buttons are too much.