techscapades

I was recently fixing a bug related to a javascript sliding animation incorrectly computing its final position. When testing the fix, QA noticed that the sliding animation exhibited a little jitter that was not reproduceable in production. At first glance, it must be the fault of a new png being too "heavy" for the browser. Let's put the old one back. No change. Crap. There weren't any changes to the easing or the duration of the animation (change focused on DOM restructuring). I was starting to feel stumped.

Just then, QA also pointed out that one of the content regions on the page in test "flashed" its reload much quicker than the production version. In production, the reload didn't happen until ~ 1/2 second after the animation completed. In our new test version, the reload was happening almost immediately during the animation (which had a duration of 200ms).

As it turns out, our test server wasn't under much load, so the AJAX request was happening in ~80ms, as compared to ~800ms in production! So now, the reloading of the content region was consuming browser resources that could be spent on the animation. Wow, What a good problem to have!

This is when I went to a crazy place.

Jakob Nielsen quotes Miller and Card et al about response times by saying::

0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

1.0 second is about the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay. Normally, no special feedback is necessary during delays of more than 0.1 but less than 1.0 second, but the user does lose the feeling of operating directly on the data.

I decided that any AJAX response < 200ms is just about the same as 200ms, especially when the users' eyes are likely distracted by the animation. I thought about waiting for the animation's complete event to fire the AJAX, but that feels like a lot of wasted time that could be processing the request. So I built a throttleAjax method that goes something like this:

/**
 * Execute an AJAX request using the given parameters, but don't let it
 * fire ``success`` sooner than the given minTime.  E.g.
 *
 *     throttleAjax({
 *         url:'/foo/bar',
 *         success:function(data) { alert('Got ' + data); }
 *     }, 200);
 *
 * Requires jQuery>=1.4
 */
function throttleAjax(params, minTime) {
    var start = new Date().getTime();
    var success = params.success || function(){};
    params.success = function() {
        var flight = new Date().getTime() - start;
        var stall = (flight < minTime) ? minTime - flight : 0;
        setTimeout(function(){ return success(arguments); }, stall);
    };
    return $.ajax(params);
}

//
// GIANT DISCLAIMER: I haven't tested this version of code, it's more or less
// an abstracted version from memory of what I wrote on company time.
//

Now, you can fire off an AJAX request, then immediately start your animation. If the AJAX by itself takes > 200ms (or whatever your animation duration is) you get the response as soon as its done. If it ends up only taking 50ms, the browser holds on to it for ~150ms before handing it off.

If you depend on smooth animations to enhance your user experience, some things really can be too fast.