The State of the Animation
The post-Flash era is hardly free of animation. CSS animation is quickly becoming a cornerstone of user-friendly UI frameworks, and JavaScript libraries already exist to handle complex, interactive animations. And now there’s a new API coming to town specifically for web animations! In the wake of so much “CSS vs. JavaScript animation” infighting, you’ll be introduced to the Web Animations API via the development styles and insights of four distinct groups of people: UI designers, interaction developers, library authors, and the browser teams implementing it.
Flash may be gone, but the era of web animation has just begun. We still really think of animation as decorative rather than useful.
“Animation is the high road to the brain’s GPU – the visual cortex.”
Large companies are now putting serious effort into their design guidelines for animation – Google, Apple, IBM all have detailed guidelines.
Kinds of animation:
- static – they run from start to finish without variation (start → end) (spinners are static. Start-end-loop)
- stateful – (default → event → predefined state)
- dynamic – multiple factors affect events, so there are multiple possible results rather than a predefined state. They determine their own behaviour and end state.
Multi-state animation is not dynamic. You can think of a venn diagram, with stateful animation in the intersection of static and dynamic.
CSS devs naturally gravitate to stateful animation as they work well with classes; which means they degrade gracefully.
Animation libraries (just mentioning two as there as so many) – Greensock (GSAP) is the most flash-like. Velocity.js is very familiar to jQuery users.
There are a lot of organisations with great internal animation libraries… but they tend to have a commercial advantage to keeping them internal, so they don’t end up being open source.
A spec you probably haven’t heard of: Web Animation API. It adds lots of features that simply aren’t available in CSS animation. It’s a long spec though – “it’s a two international flights spec…”
Naturally there is a polyfill: github.com/web-animations
Performance is important, as jank breaks the benefits of animation for cognition. Hence Flipboard’s 60fps requirement, as they consider non-janky animation to be an accessibility issue. But they used canvas which left people with nothing on other accessibility issues.
The Web Animation API accesses the same rendering engine as CSS, it will have much better performance.
csstriggers.com
Reflows are a rendering engine problem. The vendors are working on it.
The css property will-change is important to learn at this point.
The various players need to work together:
- UI Designers – get up to speed on the libraries
- Devs – check out polyfills, give feedback
- Animation library devs – read the spec, give feedback
- Animation spec authors – find better ways of taking feedback, meet people in the field
Discrimination between roles is harmful. People leave the conversation and community, then we end up reinventing and re-learning lessons.
Special announcement – Rachel is an invited expert for the W3C WG for Animation. You can talk to her. She is listening!
- rachelnabors.com/waapi
- webanimationweekly.com
- www.slideshare.net/CrowChick/state-of-the-animation-2014
@rachelnabors
Q&A
(Comment during this time) We are not our tools! We should identify ourselves according to what we make, not the tools we use.
Q: how do you avoid annoying animation?
A: if people notice it then it probably needs to be reviewed.
