I’ve spent most of this week working on making the start up experience for our applet better. It should look better, take longer and most importantly feel fast to the user. The first step is obviously to profile and optimize – the faster the start up time actually is, the easier it is to make it feel fast for users. There were a few things we could do to help out there, but nothing that really made a dramatic difference.

The next thing to do is to make it look pretty. Time flys when your having fun, and it really drags when you’re looking at a boring start up screen. There was a lot of debate about what this should entail. It’s all fancy and Web 2.0 to copy OS X’s round, indeterminate spinner. From a usability perspective that’s an absolute nightmare because it doesn’t give the user any indication about how much longer the process will take. So you really need a determinate progress bar, but apparently their old and boring. Sigh. In the end a few different ideas combined to come up with:

The outside bit spins in a very Web 2.0ish manner, but the text in the middle gives users an idea of how much longer before the editor’s ready. Given how much effort went into this it’s somewhat annoying that you really only get to see it the first time the editor loads – from the second use the editor loads so fast you hardly get to see the progress bar at all. Of course, looking at the static image I’ve been distracted and gone off to make more tweaks – who knows what it will look like by the time it ships…

The final challenge is making things pretty while the applet initially downloads the required Jar files and while Java itself starts up. Obviously, we can’t use Java code there and most disappointingly there’s just no way to know how long the jar download is going to take so we need a different approach. Sun’s heavy-handed branding of Java makes it extremely difficult to display anything more than their hideous loading screen (now bright orange!) or a static image. You can’t even get the image to resize to fit the applet area or center it within the applet. It just sits there in the top left corner and hopefully it loads before your applet does.

Looking at a bunch of other applets and even JavaScript based editors, the start up sequence is generally really lame. I’ve seen everything from a little animated GIF pretending to be a progress bar sitting just above the applet and slightly throwing out the layout of the page to greying out the entire screen and putting an animated GIF in the middle. Never mind the fact that users might have wanted to change values in other form fields, not just the editor itself. Of course, the standard technique for JavaScript editors is just not to worry about it and render in whatever order the browser manages to get toolbar icons. Usually this shows good progress to the user but it looks pretty hideous as toolbar icons randomly appear on the toolbar and the page layout shifts around during different stages of loading.

As far as I’ve seen what we’ll have once the final few tweaks are done is the best startup sequence I’ve seen – the page layout remains stable, it looks elegant, fills the space of the editor enough that the loading progress is clearly the current center of attention instead of just a progress bar off at the side somewhere and still allows the user to just ignore the editor and work with other parts of the page uninhibited. It’s also easy to modify if the default style doesn’t work with the actual site layout it winds up embedded in. I’ll be very interested to see what our clients think of it.

One thing I am really happy with is that in the last couple of days, this has been deployed to our internal systems and suddenly everyone is hugely impressed with the start up speed of our applet. The actual speed improvement is actually quite minor, but the resulting impression on the user is huge.