Say you’ve got a fancy user interface. You’re leveraging AJAX well, you’re making good use of best practices, and you’ve got fast servers that respond quickly.
But your user actions still aren’t quite as fast as you’d like. What else can you do?

If you’ve done things correctly, you’ve got a user interface that reacts positively to successful flows, but will also handle errors gracefully.
Even though you’re “doing it right,” consider restructuring your application: assume success. Normally, your server is up and running and operations
will be completely successfully. The edge case (hopefully) is the error case. Assuming this, we can create a slightly faster user interface.

Let’s begin with a basic voting mechanism. You’ve got a control on your page that lets a user vote on an object, and a small bit of text to represent the state of said control.
It may look something like this:

This example is meant to be easy and functional; hopefully your controls are prettier.
Regardless, here’s a common flow for this request and its callback states:

1. Listen for the click event on the control.
2. Send the request.
3. Display a “loading” message or a typical spinner image.
4. If the call comes back successfully, provide “success” feedback to the user and update the control.
5. If the call throws an error, provide an error message.

This flow is extremely common in today’s web. But we want something more immediately responsive, so let’s restructure the flow:

1. Use onmousedown because it will fire off just slightly sooner than onclick would.
   (This might not suit all user interfaces but in this case it’s fine, and it wins us a few milliseconds.)
2. Provide “success” feedback to the user and update the control.
3. Send the request.
4. If the call throws an error, reset the controls and provide an error message.

This structure might seem a little off. Indeed, the error case even “lies” to the user for a few milliseconds if the request fails.
But it covers all of its bases; none of the previous flow is omitted.
Keep in mind that the error case is the edge case, and a very large majority of the time it’s fine to assume success at first.

Using jQuery, here’s what the code might look like:

<br /> // Attach the mousedown event listener<br /> $(’#snappier-1-btn’).mousedown(function(e) {</p> <p> var el = $(this);</p> <p> // Go ahead and assume things went smoothly<br /> el.attr(’disabled’, true);<br /> el.next().html(’Voted!’);</p> <p> // Send the XHR<br /> $.ajax({<br /> error : function() {</p> <p> // Undo the success message and allow the user to repeat<br /> el.attr(’disabled’, false);<br /> el.next().html(”You haven’t voted yet”);</p> <p> // Let the user know what happened<br /> alert(”Sorry, an error occurred! Please try again.”);</p> <p> },<br /> type : ‘GET’,<br /> url : ‘/feed/’<br /> });</p> <p>});<br />

And here’s this flow working right here on the page:

If you’re in the bay area, check out The SF JavaScript Meetup #3, Monday, August 18th at 7:00PM. Last time, the infamous Douglas Crockford was there, so it’s sure to be a hoot! Here are the details:

As always, we will have plenty of awesome JavaScripters attending, a number of great talks on cutting-edge scripting concepts, and excellent networking potential. Come and hang out with the best scripters in the Bay Area, learn a lot, eat free food, and have fun.

The agenda

1. 7:00PM – Event starts and food (…and lots of it!) will be ready for eating
2. 7:20PM – A few words from our hosts, sponsors, and us
3. 7:30PM – An hour of high-quality talks and demos (5×12min)
4. 8:30PM – Networking, talking, learning, discussing, more questions for speakers, more eating, whatever…
5. 9:30PM – Start to wrap things up

The Address

I’ll be there, as will many of my fellow front-end engineer buddies.

Oh, and An Event Apart

Also (though I’m sure you’ve heard of this one), there’s An Event Apart: a two-day conference featuring Eric Meyer and Jeffrey Zeldman, maintained by the good folks who run A List Apart. This is another one I’m attending. Hope to see you there!