Technical • April 14, 2014 • Saurabh Nanda
We needed to build a short animation, for a client’s website, which explained a rather complex concept within 60 seconds to a “lay audience” [1]
We had never built an animation before – neither in Flash nor in HTML5. There would’ve been a learning curve with either choice. With the exception of newer iOS devices Flash would “just work” whereas HTML5 would be more of an uphill battle. However, somehow we felt more “in control” of HTML5. We would be building stuff using technologies that we were pretty good at – HTML, CSS, & JS. So, with a clear bias towards HTML5 we tried seeing if we could make it work…
There are a lot of different web technologies that are grouped together and have been given the common name of HTML5. For our animation, we didn’t need all of them. Probably just the “ element, CSS3 transitions + 2d transformations + animations + gradients, along with various other CSS3 properties like text-shadow, box-shadow, border-radius, and multiple backgrounds.
A quick glance at Html5Readiness.com and Can-I-Use gave us the following:
border-radius were supported by all the major browsers except IE8So, basically Firefox <= 3.6 and IE <=9 could cause issues with the HTML5 animation we wanted to do.
Next, we dug up the visitor stats for the website using Google Analytics.
So, it was safe to say that about 80% of our visitors would be able to see the HTML5 animation without any hiccups.
Next, we needed to pick a tool / library that would allow us to rapidly prototype the animation video over multiple iterations. Most of the stuff out there basically falls into two buckets:
While we would’ve loved to work close to the metal with JS libraries, we would’ve not been able to iterate so quickly. We took a look at Tumult Hype, but had to pass because it was only available for Mac OS X. We downloaded the beta version of Adobe Edge Animation v0.16 (then it was called only Adobe Edge) and while it had its quirks, it looked like it could help us get our job done.
So, we took the plunge into building an animation video using HTML5 using a tool that was still in its infancy!
No progressive loading: One of the first issues that we came across was that animations built using Adobe Edge were “monolithic” in nature, i.e. there was no way to progressively load the components of an animation. We wanted the animation to start as soon as the components required for the first few frames had been fetched by the browser (with the rest of the stuff being fetched in the background). Unfortunately, there is currently no way to do this in Adobe Edge.
No spriting: To make matters worse, Adobe Edge was making about 50+ individual request to fetch all static assets from the server. I guess they didn’t get around to implementing auto-spriting and JS bundling in their early releases. So, we had to do it manually. We lived with the 50+ requests during the initial prototyping phases, but for the final release we built image sprites manually. In the Edge builder each element on a frame was basically the same image-sprite cropped to a different area.
Weird JS loading issues: We probably encountered a bug in the (custom built?) async loader used by the Adobe
Edge “runtime” [2] to load its JS dependencies. About 40% of the time the animation failed to start because of certain JS objects not being defined (due to dependencies not loading in the correct sequence). deltadentalmn . We solved this by putting all the JS dependencies into a Rails manifest file to kill two birds with one stone — circumvent the bug AND reduce the number of server requests.
//= require require //= require edge_includes/jquery.easing.1.3.js //= require Slide_1_edgePreload.js //= require edge_includes/edge.0.1.7.min.js //= require edge_includes/edge.1.0.0.min.js //= require edge_includes/json2_min.js //= require Slide_1_edge.js //= require Slide_1_edgeActions.js We had to fool the async loader by loading a single blank JS file so that it would trigger the event that started the animation.
aLoader = [{ load: "/assets/blank.js"} ]; Weird Google Chrome bug: While technically not an issue with Adobe Edge Animate, we did end up hitting some bugs with Google Chrome leaving behind artifacts after CSS3 transitions. A known bug, this was to be fixed in later versions of the browser.
While we were pretty happy with the HTML5 animation – only 80% of our audience could see it. 20% of them were still left in the lurch without the animation taking them through a key piece of communication.
We turned towards conditional IE comments to help us deliver a “degraded” version of our spanking new animation to browsers unable to handle it. The degraded version was a simple slide show of static images (using SlidesJS) consisting of the most important animation frames.
We were impressed with what Adobe has achieved with Edge Animate. They have now released v1.0 of the entire Edge suite for free. (Although we hate their attempt at a private app store with the “Creative Cloud” – rant for a separate post!)
As with any new technology, we faced quite a few teething issues, but we’re sure these will get sorted out with time — as HTML5 support in browsers gets better and the tools to author rich content using these standards mature.
