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.
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
Not semantically correct
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
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.