scriptNode

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:

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

Read other articles tagged: events, javascript, jquery, optimization, tutorials

Comments (3)

• 
  January 13th, 2009 Julien Lecomte said…

  I called this pattern the “optimistic pattern” because it is based on the assumption that a request is extremely likely to succeed on the server side (if validation is properly done on the client of course) For more details, please refer to:

  http://yuiblog.com/blog/2007/12/20/video-lecomte/

  Cheers!
  Julien
• 
  January 13th, 2009 Jani Hartikainen said…

  This is a good way to make the UI snappier – provided you can actually assume it works.

  I’ve used some sites with this kind of behavior, and it’s *extremely* annoying to realize that the previous page you were on didn’t save your ajax-sent results and you have to go back. At that point you completely stop trusting the UI and have to constantly check that the changes actually were saved, and take steps like only use one UI item at a time to prevent multiple ajax requests or whatever it is that is messing up the stuff, which basically nullifies the whole point of this.
• 
  January 13th, 2009 Matt Hackett said…

  @Jani Hartikainen I certainly agree it should be used only when the error case *is* the edge case. Though it looks like Google employs this method rather effectively, it would probably fall flat on its face if used by Twitter.

Thoughts?