Thursday, May 20, 2010

Artist-Friendly JavaScript

Much has been said recently about the "death match" between Flash and JavaScript (which, come to think of it, must make Silverlight feel awfully lonely). As far as I'm concerned, we should all just get along; diversity is good. That said, I'm definitely a JavaScript guy.

It's wonderful how far JavaScript has come in recent years in terms of being able to run graphically rich experiences, but there's one crucial area that everyone seems to be ignoring: there are no artist-friendly tools for creating such experiences. One of Flash's major strengths has nothing to do with technology, per se: it's the fact that the Flash authoring environment originated as an animation studio for artists. Over the years, they've added all sorts of programmer-friendly features, but its heart and soul is still artistic creative expression.

On the other hand, JavaScript, for all its strengths, is still a programmers-only club. You can make amazing things with it, but only if you can sling the code. This locks out the very people who are going to elevate it to an art form. It's time for this to change. Someone needs to make an authoring environment for creating graphically rich, interactive, animated experiences that run in JavaScript.

That's a big task, especially if your goal is to end up with something as deep as the Flash authoring environment, but it needs to happen, and it's not going to get any easier the longer we wait. The good news is that, unlike the singular entity that is the Flash studio, these JavaScript tools can be distributed; different teams can work on different parts of the problem, integrating with common protocols that emerge. In fact, developing an open format for describing such creations would allow a variety of tools, written by any number of groups, to all interoperate.

So, what's a good chunk to bite off first? How about a simple, user-friendly web app for doing animations?

Labels:


Comments

I actually think basing something like that on jQuery (and jQuery UI) would be pretty successful.

The "common format", just becomes JSON dictionaries that you would be passing to $.animate() calls anyways.

You would have to structure it so you could say "start here, run this animation, and when its done do this and that"

That's something jQuery already supports. Might want to use some kind of "trampoline" implementation so you don't blow the stack doing recursively chained animations.

But yeah. Would be cool!
And need some tools to convert Flash to JS also...
It is a good idea. I believe that Adobe will soon build a tool like this. They theoretically don't have a stake in proprietary formats, and they have the in-house expertise to build a great tool.
The closest thing I can think of is http://processingjs.org/ which is based off of processing.org which is basically java for artists =]
Eoin, that might be a good start, but you'll soon run into the desire to have curved motion paths, which jQuery's animate doesn't support.

One thing we should do sooner than later is find some talented animators to serve as prime customers, so we know we're not making assumptions we shouldn't be.

Jeffery, yes, processing is very cool. Perhaps it would be a good underlying layer. The goal would be to not require the artist to have to touch the code.

So, who wants to help?
For a designer-friendly JavaScript tool for web apps, see:

http://280atlas.com/
Looks like Adobe is entering the fray! Very cool.

http://tv.adobe.com/watch/adc-presents/preview-of-the-edge-prototype-tool-for-html5-/

Also, here's a recent web app for creating SVG graphics:

http://svg-edit.googlecode.com/svn-history/r1771/trunk/editor/svg-editor.html

Here's the project page for it:

http://code.google.com/p/svg-edit/
@Ian- great post! FWIW, the work we're (speaking abstractly for Adobe in general) doing with EDGE is intended to make it's way back to jQuery. We're working on the timeline/motion path aspects you noted, and it's really starting to come together (as the link you posted should show) :)

Despite the Flash vs. HTML strawman debate, we've been all in on both sides for over a decade (myself mostly focusing on the latter). Let the haters hate. :)
Scott, sounds awesome! I look forward to playing with it!
Post a Comment

Subscribe to Post Comments [Atom]





<< Home