Adobe previews Edge, a prototype HTML 5 animation IDE
tv.adobe.com
tv.adobe.com
For animation, it already looks leagues better than the half-baked attempt at adapting After Effects' timeline to the Flash environment in CS4 and CS5.
Adobe always tried to make a case for Flash based on a few points that some refuse to grasp. HTML5 just can't do- or not easily at least -some of the things Flash can (e.g. webcam interaction, RTMP, multi-threaded animation).
This isn't to say that Flash is amazing, just that developers must have some kind of platform to deliver engaging, rich experiences for many reasons. Not all of them are banner ads and movie sites.
While Flash may have had many years as a cheesy intro page engine, more recent development with Flash is often an impromptu petrie dish for future advances in standards and web-based UI.
The real issue is, could implementation of a standards-based Flash variant work? And if so, how?
Certainly Adobe has pondered whether Flash would survive such standardization since we barely see CSS3 and HTML5 specs materialized as necessary.
Webcam integration: Sure, I'll buy that.
RTMP: Of course HTML5 isn't built with a technology that was developed for Flash. You know what Flash doesn't have? A <video> tag! Can equal functionality be built with Flash? Of course, very easily. But don't go calling Flash-specific protocols things that are against HTML5; that's silly.
multi-threaded animation: HTML5 has WebWorkers and multithreaded JavaScript. Not sure why you think this can't be applied to animation.
HTML5 is stronger than you think.
Likewise, a similar protocol could have been created for HTML5 video. It would be hard to argue that the web doesn't need some sort of persistence for video. Waiting for an entire video to load before you can seek to an appropriate position makes HTML5 video outright archaic in this light.
> But don't go calling Flash-specific protocols things that are against HTML5; that's silly.
It's silly to ascertain Flash as an enemy of HTML5, period. I never did. I simply implied that Flash has a leg-up in some important departments.
> multi-threaded animation: HTML5 has WebWorkers and multithreaded JavaScript. Not sure why you think this can't be applied to animation.
Let's assume for a minute that I didn't preface with "...not easily at least" and claimed that it couldn't be done at all. No matter the reach or depth of your imagination, you will not be able to conjure up a single timeline-critical HTML5+JS-based site that performs on the same level as a Flash-developed one. By that, I mean Flash is much more capable of handling vector-based and raster-based graphics at high speeds while maintaining composure. Secondly, WebWorkers and timeline animation -despite your insistence- is not easy to implement, as I earlier stated. If your statement was entirely true and HTML5+JS was readily capable of such feats, I'd imagine we'd see much less Flash games and much more JS-based ones today.
> HTML5 is stronger than you think.
I never attested that it wasn't strong. Regardless of Flash, I hope that HTML5 continues to evolve and is eventually capable of what Flash is. At this time, it is not capable and selling these false statements does nothing to help HTML5's cause.
Read more here: http://apiblog.youtube.com/2010/06/flash-and-html5-tag.html
HTML5 games work (by default) on ~50% of computers because there is no Microsoft implementation. The reason we haven't seem many games in HTML5 is because of Microsoft's lack of HTML5 support. When everyone is using Windows 7 and IE9 (with hardware acceleration, too!) HTML5 will outperform Flash and will be available on every platform.
That abuse of power has been the main problem with Flash, on Windows at least (Mac+Linux have relatively poor implementations of the player).
Basically, the benefit of HTML5 and associated technologies (seriously, that's getting annoying fast, maybe I should just rename it Superior HTML5 and Integrated Technologies, and shorten that to... nm) is simple that you'll be able to run "Flash like things" without a plug-in.
Everything Flash can do, browsers will be able to do by default. Yay. Net result? You don't need a plug-in. Everything else remains.
That's bad news. Flash is constantly full of security holes that only Adobe can fix. Flash's performance cross-platform is abysmal since nobody can fix it but them and they don't care. Fuck Flash, long live open technologies!
And just call it HTML5: everyone knows you're including the new JavaScript APIs when you say that.
HTML5 allows us to build rich applications for the web that will run on virtually every single device made (except for Microsoft devices this year, next year will change).
Don't bash tech you don't understand the benefits of.
Of course it is.
> HTML5 allows us to build rich application
Yes, I know. I love HTML5.
> Don't bash tech you don't understand the benefits of.
I wasn't bashing HTML5. I think you completely misunderstood my comment. I'm all for open standards. I never suggested otherwise.
This is an understandable concern, but at the risk of stating the obvious, HTML5 is HTML. Any HTML5 elements that irk you are available for your inspection and manipulation through the DOM. This means that sites that abuse HTML5 can be easily "patched" with Greasemonkey scripts, Safari extensions, Chrome extensions, etc.
So Adobe probably understands the issues of open/closed better than anyone, and has an organizational structure that has proven able to adapt to it.
[ Though it's worth noting that MS made an incredible sacrifice to ship windows for netbooks at a massive discount, to fend off linux. Although I use a linux netbook myself, I have to admire their foresight and fortitude. Another company is Intel. Although I don't have a specific story for them, Andy Grove wrote a book Only the Paranoid Survive, and also has a blurb on the cover of The Innovator's Dilemma ("lucid, analytical - and scary" he says) - they know the danger, and have lasted a long long time, as the driver (and proposer) of Moore's Law. ]
The reason I know this is that I'm currently building a prototype application that looks almost exactly like this, and that in its current form could produce the exact same demo in that video. Spooky, but comforting that we actually have a leg up on Adobe...
However, this is content creation - and if Adobe develop this product, they will have workflow integration with Fireworks, Photoshop, Illustrator etc which you won't be able to match. Much of the world still have slow upload speeds, so uploading assets sucks.
How will this webapp work, if its SaaS then that's a monthly sub whereas you can just pay Adobe a fixed fee?
What if I want to work on my html files, css files, and other components with my own asset management system / source control which is behind a VPN on a company server - I can't integrate that with your SaaS.
I hope you're releasing as a standalone web app I can buy and download - I don't want to invest in a content creation tool which I have to rent and could disappear.
Sometimes desktop apps are much better than web apps, and I believe this kind of tool to be one of them. I am slightly biased though because I am a big fan of the desktop app!
I've always wanted to make a similar tool for JS animations, but never got around it.
I'm having a hard time finding official/reputable info on this, so if you've seen it please share. =)
If it does just use JS for animations, it's quite deceiving to call this an HTML5 animation tool. Though I'm aware the CSS3 spec isn't officially part of HTML5, I think most people assume it is.
"Believe it or not, the biggest road block I encountered when creating this css3 cartoon was switching the scenes at the correct moment to coincide with the css3 animation. I used jquery’s built in delay function to flip through the scenes and activate the next scene."
Being able to correctly time your animation is at least as important as the effects themselves. You don't get it with CSS not even CSS3. To be more specific: http://api.jquery.com/animate/
TL;DR: the animation logic can only be done in JavaScript, CSS does not have such a feature, and it doesn't even need to because it's fine to do that in JavaScript.
When I was referring to animations, I meant the actual transformation of the element/object, which he does use CSS3 for.
I'm a jQuery user myself, along with plenty of CSS3 action, and I was indeed aware you still need to use JS for scene changes and triggering CSS3 animations.
Why I want this tool to use CSS3 for the actual animations themselves is the performance. I'm not sure what voodoo browsers use to make CSS3 animations so much more smooth then the equivalent JS animation, but it's so noticable. Especially on iOS devices.
Thanks for the link, I hadn't seen this example before and it rocks!
Hopefully Adobe carries this through to a product (or even better, a free tool?) and doesn't let it die as a prototype.
I'm surprised that you have to edit code to change parameters - I would have thought that would been natural to have in a GUI, and would give a less cluttered workflow for animators.
A nice effect having two cameras, and simple to edit between them.
Edge seems to solve a pet peeve I have with CSS Transitions: chaining animations is a drag. You gotta listen when the animation is over to fire the next one. A couple of them and your head will explode.
That said, I have encountered some stumbling blocks which Edge can't resolve:
1. No frame by frame animation. Imagine you have a large jpeg with all the frames of a video, you place it as the background of a fixed size container, and then change the background position every x milliseconds. This could be an interactive version of an animated gif, but it just can't be done with css animations. The frames slide from each frame to the other.
2. Unless your target platform is webkit under iPhone/iPad you're out of luck with the hardware accelerated 3d transitions.
3. There are no animations along a path, even though you can kinda fake it by changing the rotation origin. To be honest I think this belongs more to canvas than to CSS transitions.
I just hope the HTML & JS it spits out is nicer than the HTML that Dreamweaver spit out. :)
(1) No disrespect to John Resig, he's one of my heroes. The image was too good to pass up.
Adobe still has lots of genuine value to leech from their design tools, even if they eventually targetted HTML5 and other new technologies. I hope they won't kill this development in its infancy.
2. The demo is in Flash, so I haven’t seen it. (EDIT: This assumption is wrong, but the observation holds:) But looking at everything else Adobe has done with “HTML5” so far, I’m going to assume it’s basically exporting Flash to <canvas>. Which is, yes, HTML5, but <canvas> is no more a replacement for real HTML — you know, tags and semantic markup — than Flash is; you miss out on accessibility (often), SEO, graceful degradation, etc., and it sucks CPU cycles almost as much as Flash, because you’re drawing individual pixels in JavaScript.
I'm actually surprised someone hasn't made a tool like this for jQuery. I know jQuery and jQueryUI have basic animation support and likely some plugins that build and extend those features, but a dedicated tool for creating advanced timeline and event based animations would be amazing.
My point, though not complaint, was that it's more geared towards executing a single animation against a single DOM element or a group of DOM elements. This is incredibly powerful, but when you want to start chaining animations, or "firing" off additional animations when you're mid cycle on your first animation - it gets tricky.
For example doing something like...
$("#myDiv").animate({top: 50}, 1000, function(){ $("#myDiv").animate({left: 50}, 1000) });
Would move "myDiv" down from 0 to 50 over 1 second and then move it right from 0 to 50 over 1 second. But if I wanted to trigger the left -> right animation midway between the top -> bottom animation there isn't an easy way to do that as far as I know. Currently you'd have to create two top -> bottom animations and split up the distance and duration so you can interject the secondary animation.
$("#myDiv").animate({top: 25}, 500, function(){ $("#myDiv").animate({left: 50}, 1000); $("#myDiv").animate({top: 50}, 500) });
That or just execute the 2nd one with a timeout independent of the first...
$("#myDiv").animate({top: 50}, 1000); window.setTimeout($("#myDiv").animate({left: 50}, 1000), 500);
Neither of those "solutions" are terribly difficult, but it gets more and more complex when you start building on it. If Adobe's EDGE or another set of tools would give you the ability to do this easily, I'd happily pay for it. Anyway, I suppose I'm getting off topic. :)
TL;DR: Doing animations in web applications is hard for all the wrong reasons.