has_many :thoughts

Parts of an upcoming project make calls out to an external service that can take several seconds to respond. As everyone knows, the attention span of the average idiot web surfer is closer to a few nano-seconds. And so, we use AJAX loading indicator animated gifs to show the user something is happening.

However, several pages perform this call on their initial load. So an AJAX loading indicator won’t do the trick—the indicator has to appear on the preceding page in the navigation process. And so, we created some Javascript that would simply unhide an animated gift next to a “Next Step” button when the button was clicked. This provides some feedback to user that the next page is loading. (The user could, of course, note the status of their own browser’s load-indicator, but I suspected many wouldn’t.)

This seemed to be working great until solid IE testing began. We soon discovered that as soon as navigation away from the current page has begun, IE stops all animated gifs. The result is a rather unhelpful seized-up spinner-gif that actually makes the user think something went wrong.

So instead of an animated gif, we now use the lovely effect features of script.aculo.us to fade a non-animated hourglass icon in and out when the button is clicked. Some JS like this…

Effect.Pulsate(icon, {
    duration: 100, 
    pulses: 95
});

...results in something like this:

The net result is the same: the user knows something is happening behind the scenes. But now, at least, it plays nice with IE. Seems that IE lets JS effects like this go on even after the call to the next page has begun.

In retrospect, it might been best to ensure that our page loads didn’t call the external service directly. But rather, load the next page rapidly and then made an AJAX call out to trigger the slower service. That way, we could have avoided these issues all together and used the traditional, in-page AJAX loading animated gifs.

Oh well. There’s always version 2.0.