Personally, I was involved in running the Parapara Animation Workshop* where kids enjoyed drawing simple frame-based animation on a tablet which was then added to a much bigger animation projected on the walls. The purpose of the project was to teach kids the basics of animation as well as to encourage them to be not just web spectators but web makers.

It’s a workshop that was originally done by a group of Keio University Students and they helped run it again this time. The main difference is that last time it was mostly iOS-based, this time it was all Web.

Christian Heilmann has written up a great summary of this part of the program including a quick interview where you can see how it worked.

Japanese kids are really creative so it was a really fun time. But not only was the event fun, the technology side was really fun too.

Some of the technology used

• SVG—heaps of SVG. The hand-drawn paths, UI widgets, all of the animation, all of it is SVG. In particular we used a lot of SVG Animation and even SVG applied to HTML to provide the glowing effect on the form text (as per the designer’s prototype—not my idea!)
• Fennec (Firefox for Mobile)—Just a regular release build (version 9), plus Matt Brubeck’s Full Screen add-on and a few config tweaks.
• Touch events
• CSS calc
• CSS Transitions

What went well

• SVG’s native motion on a path (<animateMotion>) saved us so much time. The auto-rotate feature (rotate="auto"), path APIs (getPointAtLength), and ability to calibrate the path length (pathLength="1") also made it easy to position animations at just the right place so they would appear on the screen as soon as the user pressed “send”.
• Using SVG made it really easy to do the drop shadows. Just a transform and a blur filter and we were done.

  

• SVG animation was surprisingly fast. I expected it to be really slow but it was the fastest of the alternatives we tried. That said there’s still a lot more work to be done (see below).
• Overall SVG just proved really versatile. Being able to show a faint greyed outline of previous frames just by setting an attribute was great. Likewise being able to do all the animation work on the client-side and then just serialise the subtree and send it to the server was so much simpler than the previous version.
• Deployment over the Web was great. Just refresh the page to pick up the bug fixes! Likewise when we ran out of tablets at one point we could just load up the editor URL on a laptop and keep drawing.

What didn’t go so well

• The app marketplace. We badly wanted to package it all up as a Web app using the framework developed by the Mozilla Labs Apps project. We hoped that would give us full-screen display and stop the user from accidentally navigating to other pages. We had high hopes but were shattered to find the Android runtime launched the app in a Webkit runtime which didn’t even support SVG.
• Going full-screen. Due to some technical reasons we were stuck with an old version of Fennec and old UI which took some coaxing to go full-screen and stop the chrome from flying in when the user was drawing. Fortunately the bugs that stopped us from using a more recent version of Fennec appear to have been fixed so next time we can hopefully use the Fullscreen API and multi-touch for drawing with all your fingers at once (something the really young kids really wanted to do!)
• CSS and UI layout. Countless hours were sunk into trying to convince CSS to layout widgets on the screen. In the end I gave up and did half of it in script. I’m told CSS flexbox can help a lot here but I spoke to one implementer of flexbox who said that some of the things we were trying to do weren’t possible even with flexbox.
• Graphics performance. For the combined animation we badly need a boost to our SVG rendering performance. On Windows the performance was generally ok (if you don’t have a loud fan!) but occasionally got jittery. On Mac it looked terrible. We still have a way to go here. Apart from the graphics performance there’s still lots of room to optimize SVG animation itself too. For the editor running on the tablets, I have one patch awaiting review which I hope will make using SVG’s path APIs faster and speed up the drawing and erasing operations.

The result

The gallery of animations:

http://parapara.mozlabs.jp/MozillaVision2012/

The editor:

http://parapara.mozlabs.jp/MozillaVision2012/editor/

And, of course, the code is waiting for your help at github!

Feedback

“That’s a web page?!?” I’m certain that most people who used the demo were oblivious to the fact they were using the Web and that’s probably the greatest success of this demo. Without exception, everyone who asked about the technology was surprised it was Web-based. Everyone assumed it was a native Android app or otherwise Flash.

“That’s SVG?!?” The web developers who came were also surprised at the use of SVG. Most had never really thought of making use of it. They assumed we were using canvas.

“I want to cry, this is the first time I’ve seen Fennec used for something other than reading the news”

Although a lot of the features we used are still in development it was very rewarding to see how much is already possible with Open Web technologies. We’ve had many requests to run this workshop elsewhere and, with your help, it will hopefully get better each time. Thanks very much to the Parapara Animation team and to everyone who contributed to Fennec, Gecko and the Web standards that this is built on.

* For anyone wondering what “parapara” means, it’s the sound of flipping paper and its use here comes from “parapara manga” which means “flipbook comic”. It’s also the name of a kind of hand dancing so we might have to reconsider the name so as not to disappoint the kids.

There’s CSS transitions for all sorts of animated eye-candy, major JS speed-ups to give scripted animations a boost and mozRequestAnimationFrame to get keep them smooth and in sync, and a whole host of other graphics and video improvements. Oh, and SMIL in SVG!

Speaking of which, I thought I’d bring you up to speed on some of the recent progress on the SMIL front.

Event timing

One of the more recent additions to our implementation is the ability to key animations off DOM events such as mouse clicks and key presses.

This paves the way to creating widgets of questionable aesthetic value:

(View demo. You’ll need to be running a recent nightly to experience this button is all its tacky glory. With the latest Firefox 4 beta the motion will be jerky due to bug 557885.)

However, SMIL animations need not only be keyed off SVG events but any event in the current document is fair game. So, for example, suppose we want to add a tape animation that runs whenever a certain video is in play, we can do it with this piece of SMIL:

(View demo)

In addition to events, you can also key animations off:

• key presses: <animate begin="accessKey(a)+1s"…
• other animations: <animate begin="otherAnimation.begin-2.5s"… (and this is generally a much better choice than event timing when you want to keep animations in sync. Although you can write begin="otherAnimation.beginEvent" you may get surprising results when a seek is performed. Use begin="otherAnimation.begin" instead.)
• repeat iterations: <animate begin="otherAnimation.repeat(2)+25ms"…
• plain old time offsets: <animate begin="12.3h"…
• all of the above! <animate begin="rect.click; accessKey(a)+1s; otherAnimation.begin-2.5s; otherAnimation.repeat(2)+25ms; 12.3s"…

SMIL and script are friends

There are a lot of advantages to using SMIL over script (it’s generally easier for a start!) but sometimes it can’t do everything you need. In those cases you can use both together!

SMIL → Script: To synchronise script with SMIL, just listen for the relevant time events generated when animations start (beginEvent), repeat (repeatEvent), and stop (endEvent). If you need a bit more context you can always query the animation’s start time and current time too.

Script → SMIL: To go the other direction, that is, to kick-start SMIL from script, just use the appropriate time control interfaces beginElement, endElement on the target animation, or seek and pause all animations in the <svg> block as a whole with setCurrentTime, pauseAnimations and friends.

SMIL outside the box

While we’re only supporting SMIL for SVG content that doesn’t mean it’s entirely off limits to your HTML content. Not only can we tie SMIL to HTML events as above but we can also apply various SVG features to HTML, and these places can play host to a bit of declarative animation too.

(View demo)

What’s left?

Still, there are a few features missing in our SMIL implementation that are yet to come. I’m maintaining a somewhat detailed summary, but in short we’re missing:

• Mexican waves — There are still a few SVG data types that can’t be animated yet. Paths are very much on the way, but lists of points are yet to come. That means all your squiggling, warping, barrelling, twisting, waving lines and stars will have to wait a little longer to mesmerise the world. Hopefully most of this will be done in time for Firefox 4.
• Hyperlinking — The ability to trigger animations from a hyperlink is also yet to come but will probably not make it’s debut until after Firefox 4.0.

What’s not on the radar?

There are also a couple of features that are neither done, nor likely to get done in the foreseeable future. These are:

• <animateColor> — So long as <animate> honours color-interpolation then <animateColor> isn’t necessary and only complicates the Web. See bug 436296. We recommend using <animate> instead. (This issue was recently discussed on www-svg.)
• Wallclock timing — That is, the ability to set up an animation to begin at 2011-01-01T00:00:00+09:00. Real uses cases for wallclock timing were discussed on www-smil earlier in the year but it seems the syntax provided by SMIL, at least as far as it is used in SVG, is insufficient for these use cases. For the time being, we’d rather not clutter the Web platform by implementing something half-baked. For most use cases, it should be possible to provide this sort of functionality by adding a sprinkling of script to your SMIL.

UPDATE: I just noticed Robert Longson (who’s played a big part in us getting to this point) beat me to reporting much of this news, so for more details on where we’re up to see his post too.

I thought I’d just take this chance to acknowledge some of the people who’ve helped get us here. Particularly Daniel Holbert for his incredible helpfulness and for just being awesome at everything he does; Jonathan Watt for all his help with SMIL recently and for always looking out for me; Robert O’Callahan for his oversight, invaluable input, and support technical and personal; and Chris Double for keeping SMIL moving in the early days.

Also, as alumni of the University of Technology, Sydney (UTS) I used their library a number of times last year as a kind of virtual office. It’s a great library where they really try to help the students, allow you to eat at your desk, and even let you pay for your fines with canned food that is then given to an Australian charity group. Thanks UTS!

Finally, thanks to Solutions First, specialists in Open Source and Linux solutions and a whole lot more, and who have generously provided me with this web space for longer than I can remember. Cheers guys!

This weeks developments:

• <animateTransform>
• SVGAnimationElement interface
• Fixes to better synchronise the DOM state with the animation state
• A couple of other small fixes

Today I ran up against some questions about zero-length intervals so if you have any insights there I’d be glad to hear from you! I’ve adjusted our timing model based on what I think SMIL intends.

That brings to an end my stint with the NZ office. I had a great time with the fellas here–cheers guys! Or as some people here say, “chur!”

But althought we’ve come a long way I want to emphasise that we still have a long way to go. I’ve updated the status page to give you an idea of the features still remaining to be implemented. In particular, integration with SVG and CSS is a massive task (although it makes up only two rows of the chart) and by far the bulk of animation demos and tests won’t work without this. Also, syncbase timing is a big job.

The good news is <animateTransform> is in the pipeline (ready for review any day now) and for maybe the first time ever, there’s a little bit of momentum behind SMIL.

Update 16 Feb 2011: Thanks to Patric Conrad for a Belorussian translation!

Here’s the low-context summary:

• Daniel Holbert has been taking on this work and pushing it along steadily (thanks a million Daniel!!)
• I’ve joined the Auckland office for my summer break (from December to the end of January) to work full-time on SMIL.
• A (very) basic patch is nearly ready to land after it undergoes some final review and rework. After that SMIL should be on the trunk but disabled by default. I’ve updated the status page to reflect the features of this patch.
• A proper implementation of <animateTransform> is also ready but needs review. I’ve written up (in painfully boring detail) some spec issues I encountered regarding <animateTransform>.

Next on the agenda I hope to be working on syncbase timing.

Thanks again for all your support and Happy New Year! Godt nytår! あけましておめでとうございます！ 新年もよろしくお願いいたします！

From now on, if you want to track the progress of SMIL in Mozilla I recommend:

• #216462 Implement SVG (SMIL) Animation
• tor’s weblog

As for me, I’m travelling around Asia (check the blog [removed] if you’re really curious), so unless someone can sponsor me to work on this in Asia I can’t really offer much time to the project.

Thank you to everyone who helped me to get SMIL this far. I hope that someone else can pick it up.

Progress on SMIL continues, albeit in slow motion. Just a really quick note for those one or two people who want to know what’s going on:

• Not only does it compile it now runs too!
• All my visual tests pass again
• All my unit tests pass again
• My early attempt at <animateTransform> is up and running again and seems to work.

I need to do some tidying up before it’s ready for review. Most of all:

• Some deCOMtamination
• Making better use of Moz utilities (string iterators, nsTArray etc.)
• Removing redundant code
• Fixing the scope of the animation controller

It’s hard to give a timeframe for this – it depends a bit on my workload with other things (Japanese, Bible college, surfing, life – not to mention my day job). Hopefully a month?

As for new feature work, I’ll have to re-negotiate with work before I can do that. So I’d really appreciate any help at all. The SVG guys have already been incredibly helpful and have begun preparing the SVG code so it can be animated more efficiently. Thanks guys!

Thanks to the many people who have left very encouraging comments in the meantime. I’ll do my best to get this up and running as soon as possible. One very experienced developer has suggested they might be able to contribute which would really help bring this to reality.

I’ll wait until it’s actually working (and I’ve done some more deCOMtamination) before posting another patch. But thanks for being patient with me!

• http://brian.sol1.net/svg/report/report.pdf

Also, I was invited to represent the Software Engineering faculty by presenting my project at an Engineering project competition run by my university from which I picked up the prize for innovation which means I got paid for working on Mozilla! Stoked!

Finally, I’m taking a bit of a break from this work at the moment. I nearly went crazy finishing the uni project last year and right now it’s summer so I’m getting back into surfing, swimming, running, riding, squash and maybe even some karate! Maybe in a month or two I’ll be ready to look at the code again and I’ll try to tidy up the SMIL Animation code.