Much like a magpie, I find myself oddly infatuated with shiny things. When a UI component somewhere just screams elegance, I find myself compelled to use it. A lot of the time a simple right-click will indicate the said UI was implemented in Flash, and it loses a tiny piece of street-cred.

I’m most impressed by FX when they enhance the user experience. By using subtle FX during transitions (or an element fading out rather than harshly ‘disappearing’ for example) we give our users an added element of flair while requiring nothing of their browser other than JavaScript being enabled. Any marketing type will tell you the value of a first and lasting impression. The UI really is the only thing the customer sees, isn’t it?

I’ve always been in love with Dojo’s Animation API, though in 0.4 it was a little grotty. Some functions were in dojo.html.fx, others in dojo.lfx, and the different functionality put into different modules was slightly painful to be honest. It was functional, and a good FX system, though it lacked definition. I’ve taken a personal interest in Dojo FX since day one, and have worked tirelessly with other Dojo’ers to bring it clear definition.

I was tinkering with one of my favorite Dojo methods: dojo.animateProperty last Sunday (yes, I do this for relaxation, too.). New in Dojo 1.1 was a nice new shorthand API I’d yet toy with, and was excited to get going. I managed to come up with a simple animation sequence I’d like to share. Using images stolen from my employer (does that count as office theft?), I created a clean and responsive “Demo Animation” (and inadvertently wrote an image pre-loader, for what it’s worth) based on the SitePen logo.

You can checkout the animation using the AOL CDN.

The current state of browsers dictates the sequence is best viewed in Safari 3.1, FF3, FF2, IE7, Opera, and finally IE6, though even there it performs surprisingly well—much better than I had anticipated. The bottleneck is the loading of the images, which we subvert by using a splash loader and waiting until our required images have fired onload before even beginning the animation.

This example is a testament to the talent the Dojo Developers possess. SitePen’s Eugene Latzukin, Bryan Forbes, and Alex Russell all played a pivotal role in the increased performance in Dojo’s Animation class. The accuracy in timings, lack of visible latency, diversity of the API, and the overall control over the DOM that dojo.fx provides is amazing to me. The ability to chain and combine that number of animations with varying durations and delays and easing effects, and still maintain the performance of a single animation….phenomenal.

Size notes:

There are three versions of the dojo.html demo: one from an uncompressed trunk checkout, one from dojo-mini 1.1, and one using AOL’s CDN copy of 1.1. The size of the build doesn’t seem to affect performance, though it dramatically affects load time.

	trunk: 41 requests /  354k /  1.22s
	mini:  22 requests /  153k /  1.1s
	aol:   22 requests /  90k /  1.22s

The images total 54k of the total transfer. Passing the sitepen.js through ShrinkSafe cuts it from 7k to 3k. Every byte counts.

The demo uses some small Dijit methods that might not be needed ultimately. Using a custom build, we could get the number of JavaScript requests down to two: dojo.js and a large sitepen.js which contains the code from the dojo.requires() atop it.

Performance Issues:

Image sizes. The slowest responding aspect of the demo is the exiting animation when you click the logo. I will admit it was poorly designed, and was the last step along the way. Currently, it is animating the width, height, top, left, and opacity for each of the nine images on the surface, then playing the resultant combined animation. Dojo’s timing code makes it accurate, but on slower browsers that aspect may seem choppy. I can reduce the number of animations needed from 45 to 5 by replacing my 9 images parts with a single image. Perhaps the reduced calculations (re-scaling of the images vs. a single image) will improve that feature.

Obfuscation:

Having no real goal on said Sunday afternoon, this demo was just kind of pieced together, and consequently slightly obfuscated. I’d toy with one set of calculations, and move on to the next, while adding a new combined animation every time some new way to test the 1.1 FX API came to mind. The result is sloppy code with blocks commented out, redundant variables floating about, and other strange techniques. There are also very few comments inline, for which I apologize. Having no direction and changing the whole demo time and time again discouraged me from documenting the code.

I also did silly things like:

	var _d = dojo;
	var $ = dojo.query;

… making the code even more difficult to read.

update: I have since returned the stolen images to my employer.