Let's talk about Adobe's Edge Animate

animation / css / design / development / html / javascript / motion graphics   Posted on Jan 3, 2013 by Darin Senneff

Let's talk about Adobe's Edge Animate

Back in September, Adobe released its new HTML animation software, Edge Animate. After initially releasing Adobe Edge as a free preview available in Adobe Labs back in August of 2011, Adobe has now renamed the program Edge Animate, while introducing some other design and development tools alongside it under the new Edge Tools umbrella. The Edge Tools set is Adobe's new foray into embracing web standards, by developing software for users to create responsive, interactive, standards-compliant content that the web community has seen a major push for over the past few years. 
Edge Animate, simply put, is an animation program that could be seen as the "new" way to create web animations and interactions to replace its trusty stalwart, Flash. Flash has been around for years, and the Flash Player, which runs the content, is installed on over 99% of desktop computers. The problem, though, is that because the "new" web features smartphones, tablets, televisions, video game consoles, and other devices connecting to it, Flash isn't really a viable way to deliver content to users anymore. This can be boiled down to various reasons, but the long and short of it is that the Flash Player's incompatibility with so many devices means that it's not effective anymore. 
Where Edge Animate comes in is that Adobe is hoping for it to pick up where Flash has fizzled. While modern devices and browsers don't agree with proprietary plugins like the Flash Player (or Microsoft's knock-off, Silverlight), they do support web standards like HTML and CSS, and Edge Animate outputs just that. Edge Animate features a timeline, stage, and tools similar to Flash, only instead of a SWF, it generates HTML, CSS, and JavaScript markup for you. I've spent some time lately using Edge Animate and while it's a great tool, I am left feeling pretty underwhelmed. First, the pros:



Intuitive, familiar interface

If you've ever used other Adobe products, or specifically Flash, then the UI of Edge Animate will look familiar to you and the learning curve should be rather small. In fact, it reminds me of an older, more primitive version of Flash, maybe version 5 or MX. The UI features a stage, timeline, toolbar, and properties panels, which are pretty standard across animation software. 

Ease of use

Adding elements to the stage is as simple as dragging them from the toolbar and dropping them onto the stage where you'd like them. You can click on existing elements to move and reposition them, or to adjust their appearance in the properties panel by changing their values. Animation can be added by placing keyframes on the timeline and creating transitions and changing the beginning and end states of that object. 

No coding necessary

As with a lot of Adobe's products, Edge Animate doesn't require you to know any coding to use it, as all relevant programming is generated behind the scenes as you create. Once you're finished, simply publish your work, and Edge Animate exports the HTML, CSS, JavaScript, and images for you to add to your web project or send to the developer to implement. 



Not semantically correct

Edge Animate's marketing is pushing it as a standards-compliant way to incorporate animation into your websites. I'll get into this deeper in the next point as well, but the HTML product of an Edge Animate project is far from semantically correct markup, which is one of the core principles of the web's push for HTML5 and the adoption of standards. For starters, every element on the stage in Edge Animate is created as a DIV in your HTML element with inline styling. If you have anything more than a few objects, then now you have a bunch of empty (unless you've added text) DIVs. The DIVs are then animated via JavaScript triggering their CSS properties. 
This type of animation can be called DOM (Document Object Model) animation. Essentially, the browser sees your HTML document as a tree of elements, this is the DOM. So, everything that moves in your animation must be an HTML element accessible through the DOM. There's nothing wrong with this type of animation, as I think it has its place here and there, but I believe Adobe could've been a bit cleaner with their approach.
In order to move the web forward and produce cleaner, more usable sites, we need to start correctly using HTML. A DIV element is meant to define a section or group of HTML elements into one related packet. By potentially having dozens of empty DIVs with no clear semantic value, we are actually moving in the wrong direction for web standards, which was one of the main ideas behind moving away from technologies like Flash in the first place. In my mind, Adobe is simply introducing a slightly-better alternative for motion graphics rather than a major step toward a long-term solution. 
To piggyback on the empty DIV party, I think that it'd be nice to be able to use different HTML elements in my Edge Animate project other than a DIV. What if I have a button, why can't I correctly categorize it as an A or INPUT[TYPE=SUBMIT] element? Or, if I have a block of text, I should be able to set it as a P, H1, H2, BLOCKQUOTE, or whatever element it actually is. A feature like this would help to make the semantics argument I mentioned earlier just a bit more bearable.
Lastly on this point, let's say I want to use a gradient in my animation's background. To accomplish this task, I am required to import a bitmap of the gradient, which is then set as the background-image CSS property of the animation's container DIV. Now, there's nothing wrong with this, but I feel that we could leverage the fairly decent support of CSS background gradients rather than dealing with loading an external image, which allows the element to be much more editable and scalable/crisp once you get into mobile and responsive territory. It's just adding an additional step that I feel could be a much more friendly and manageable property. 

No support for HTML5's CANVAS or SVG

As I mentioned above, I don't find the appeal in cluttering your HTML document with 20 empty DIVs to be used for motion graphics. What if your document's stylesheet isn't loaded for whatever reason? Then, your user sees a bunch of empty containers, and your important content may be buried down somewhere out of sight. A DIV isn't meant to be a graphical element, but know what is? The CANVAS and SVG elements. Now, I'm not going to get too into what these two elements are, since that could be a whole series of blog posts themselves, but they are designated graphical elements that are used to draw and display graphics on the fly via scripting. Now, support for CANVAS and SVG is pretty decent currently, but it's far from fair-play across all platforms and devices, due to both browser and processor concerns. 
I would've liked to see Adobe push the industry to improve the support for these HTML5 elements by building Edge Animate to utilize these methods. If you have a great product with a lot of promise, then the browser companies and device makers will be sure to improve their support so that their users may experience them. Or, at the very least, how about upon opening a new project, you give us the option of building our end animation based on the CANVAS, SVG, or the DOM animation using DIVs and other HTML elements. 

Inefficient animation processing

This is more of a minor gripe when compared to the first two cons, but the animation platform in Edge Animate is powered by jQuery. Now, jQuery is a robust, invaluable JavaScript framework, but it was never intended for advanced animations. In fact, jQuery's animate() function gets bogged down easily under pressure and results in speed loss. If you're animating several elements at once as I assume most Edge Animate projects are, I feel using another JavaScript library that is more animation focused would have made an overall better product. A couple of good options would have been the Greensock (GSAP) and TweenJS libraries.


Adobe's Edge Animate is a simple, yet powerful tool to help you create HTML animations fairly quickly and easily. I feel that it's more geared toward designers that don't know (or care for) code, and just want to get up and running quickly with little concern for what's happening behind the scenes. At the same time, I feel that it leaves a lot of be desired in terms of web standards, pushing for the future with support for CANVAS and SVG, and could use some more robust (and efficient) control of animations and elements. I will keep my eye on it for sure, and possibly use it for some simple things here and there, but I will be more anxiously awaiting the correction of some of these flaws and shortcomings. 

Search the Blog

Blueprint Tweets

READ IT NOW: Our digital campaign experts on how to plan a crazy good digital ad campaign https://t.co/peA2arPgcG https://t.co/H07DkMVzoq

Friday September 22, 2017

Get your groove on! Today's #MorningMeetingSoundtrack is Back Pocket by @vulfpeck https://t.co/mXkuKy4QSz

Friday September 22, 2017

Dropping knowledge with the help of GIFS. Six steps for creating an #amazing #dope #ridonkulous digital media plan… https://t.co/Evz8ienKFU

Thursday September 21, 2017

Visit BlueprintTweets ›

Contact Us



1155 Connecticut Avenue, NW
Suite 601
Washington, DC 20036

Or submit your info and let us know what we can do for you!