DailyJS: What makes animation exciting in 2015—compared to the older Web 2.0 animation libraries?
Julian: We have faster browsers today, and they're only continuing to get faster at an impressive rate. The Chrome team, in particular, also happens to be aggressively pushing to standardize browser behavior on Android. Those two factors, combined with the increasing computing power of mobile devices, means that Web animation performance will continue to improve -- even if developers' implementations stay stuck in old ways.
The other predominant trend in web development performance is simply its broader awareness, along with the increased importance being placed on it. Fortunately, performance is no longer a second-class citizen in web development education and industry news outlets. With broader awareness comes broader implementation and deeper understanding of best practices. Since there is a lot of low-hanging fruit that can be picked in web performance, this too will result in significant gains in site performance and usability in the coming months.
All of this leads to a performant base web development platform upon which beautiful and fluid animations can be layered. The higher we can push animations to perform -- across all browsers and devices -- the sooner the slick motion design commonly found in mobile apps will exist without compromise on the Web.
DailyJS: What trends will we see in the future of Web animation?
Julian:We might see a wave of too-clever and overused motion design in web user interfaces. Are you familiar with those awesome-yet-crazy After Effects-produced motion design examples on Dribbble? Those will become a technical reality on web pages soon enough. Like all things, however, I think the wave will peak then collapse, and we'll settle into a happy medium of quality user experiences bolstered by motion design that doesn't detract from usability.
In terms of trends, the inevitable growth of React Native might mean we'll also see a large shift in the tooling landscape toward the React ecosystem. I wouldn't be shocked if React is the future of web programming as we know it. If this turns out to be the case, animation engines will have to follow suit or they'll otherwise become irrelevant.
DailyJS: What animation anti-patterns should developers and designers be aware of?
Julian: Utility and elegance are the goals of all great Web animation. Great animators deliberately choose every aspect (e.g. easing, target properties, duration, and so on) of their seemingly arbitrary animation sequences -- because they want to reinforce the intentions of a UI, and that's a very calculated decision. Whimsical motion design, in contrast, is not only inconsistent, but it also appears inelegant and diverting to the user.
The sad truth is that -- while there are hundreds of tutorials on the minutiae of UI design -- there is very little education on motion design. They're both very important aspects: Whereas UI design lays the structural foundation for interacting with a web page, motion design enriches that foundation with the furnishing and decoration that make the page usable and comfortable. If you allow me to be metaphorical for a moment, furnishing is the utility that motion design serves, and decoration is the elegance it provides. Great apps leverage both utility and elegance to make the user feel like they're interacting with an interface that's living, breathing, and tangible. In contrast, an interface that's devoid of motion design reminds the user that she's simply dragging a cursor across a screen or tapping her finger on a piece of glass. In other words, a web page without motion design can make the user painfully aware of the artifice before her.
With that context out of the way, common anti-patterns include:
Employing one-off motion design interactions that break from convention: The less you copy motion design from existing popular apps and sites, the less familiar your interface will feel to the user, and the less confidence she'll have when using it. While there's utility in novelty, the motion design of everyday UI elements shouldn't be novel. It should be reliably obvious.
Allowing complex animation sequences to consume a large total duration: Developers often make the mistake of letting animations run too long, causing the user to wait needlessly. UI flourishes should never slow down the apparent speed of a page. If you have a lot of content fading into view within a larger animation sequence, ensure that both the individual animation steps and the total animation sequence duration are kept short. Don't lose track of the bigger UX picture. Since it's difficult to judge the appropriateness of your animation durations after seeing them play out dozens of times during development, a good rule of thumb is to speed up all animations by 25 percent before you push a site to production.
Being frivolous: Interface developers should regularly be downloading the most popular apps, playing with them extensively, and judging whether they feature animation to a greater or lesser extent than their own work does. If they feel that the apps use animation to a much lesser extent, they need to consider toning back the motion design in their UI. Simply, if a particular piece of motion design doesn't provide psychological utility to the overall experience (affordance, clarity, connection, etc.), then its inclusion should be reconsidered. Injecting motion design for its own sake leads to bloated interfaces.
Not experimenting: Finding the right duration, stagger, easing, and property combinations for each animation is not a skill that designers are simply born with. It's a skill that every great developer-designer has had to hone. So, remember: your first attempt at a combination of animation properties might look good, but it's probably not the best combination. You should experiment by systematically changing each factor in the motion design equation into you stumble into something sublime. Once you've found a combination you love, experiment even further. Consider cutting the duration in half, switching to a completely different easing type, or swapping out a property. Designers are often averse to repeated experimentation because they believe in the sanctity of their whimsically-derived creative nuggets of insight. But insights have relative value, so it's important to get outside of your comfort zone to see what else you can come up with. Professional developers should strive for greatness, not goodness. Greatness always entails experimentation.
I've written a lot about these theoretical aspects of motion design in my book, which also dives into the topics of animation performance and animation workflow.
I usually write CSS animations by failing to remember the syntax and then copy and pasting examples until it works the way I want. In times like that a handy directory of CSS animations is essential. AniCollection (GitHub: anicollection/anicollection, License: MIT) by Dariel Noel is big collection of CSS animations. Each animation has a preview and the associated CSS in an easy copy and pastable format.
var fetch = require('superfetch');
// when the status code begins with "2", the response body will be returned.
// otherwise, the whole response(including headers) is returned.
You can use fetch.get.option to set options, and you can chain calls to option if you like. The request and response objects can be transformed with callbacks, and the author has included unit tests written with Mocha.
PWS Tabs (GitHub: alexchizhovcom/pwstabs, License: MIT) by Alex Chizhov is a jQuery plugin that helps you create modern, flat tabs, with CSS3 animations and Font Awesome Icons.
It uses data- attributes to set the tab's title and icon. The $(selector).pwstabs method accepts options for the tab position (horizontal or vertical) and the animation effect name.
The plugin source itself is fairly leightweight, and it comes with examples that include CSS. When I reviewed this plugin I had to download the examples because I couldn't access Alex's site, but he does link to a live demo in the readme.
wheelnav.js (GitHub: softwaretailoring/wheelnav) by Gábor Berkesi is an SVG-based library that you can use for a centerpiece animated navigation component. This might work well for a marketing website, which is the example Gábor uses, but I think it would be really cool on a child-friendly site with lots of bright colours site as well.
Tadeu Zagallo sent in a Canvas experiment that uses typed arrays, optimised sorting algorithms, and inlining and bitwise operators to boost performance. The Particture demo allows you to use your webcam for the source image, and draws images with a cool trail effect.
Many readers seem to be searching for solutions to the module refactor problem, where older projects are refactored to use modern module systems. Dustan Kasten wanted to convert projects that use AMD to CommonJS, and he's used Recast to do this, through the recast-to-cjs project that is published by his company (Skookum Digital Works).
It's possible that Node developers may end up doing something like this if ES6 modules become the norm, although I suspect ES6's export and import statements will need manual intervention to take advantage of import obj from lib.
Tweene (GitHub: SkidX/tweene, License: Artistic License 2.0, npm: tweene, Bower: tweene) by Federico Orrù is an API that wraps around popular animation libraries so you can switch implementation more easily. Rather than having to worry about whether you need to use translateX or just x, you can use Tweene's API instead.
To create animations, you have to make tween instances using Tweene, and then call methods that set the duration and easing. It actually has several API styles based on GASP, jQuery, and Velocity, but I prefer the fluent API:
This specification defines a new form encoding algorithm that enables the transmission of form data as JSON. Instead of capturing form data as essentially an array of key-value pairs which is the bread and butter of existing form encodings, it relies on a simple name attribute syntax that makes it possible to capture rich data structures as JSON directly.
This basically means you can use an enctype attribute of application/json in forms. This makes it a lot easier to create forms that send data to JSON APIs, rather than using the standard form encoding.
Cezary's project allows you to use enctype='application/json' and then get JSON out with $(formElement).JSONencode(). You can also enable and disable the plugin.
The HTML JSON form specification is new to me, but it seems really cool for those of us who create lots of JSON APIs.