Remote Scripting with AJAX, Part 2

Editor's note: In part one of this two-part series, Cameron Adams created an example application that shows how to use remote scripting to implement the AJAX XMLHttpRequest protocol. Now, in part two, he shows how to create a usable interface for the example app.

The content for this article was excerpted from Cameron's originally published article, which was posted on SitePoint's website last month.

To begin, download
the code archive, which contains all of the files you'll need to create
the working examples presented here and for part one of this series.

Create a Usable Remote Scripting Interface

The remote scripting model is quite different from the standard page-based
interaction that permeates most of the Web, and with that difference comes
new usability pitfalls
that can too-easily be introduced into your projects. These pitfalls typically
arise either from the dynamic manipulation of the interface while the user
is accessing it, or from the need to access data that's external to the web
page.

Example 1 used remote scripting to validate the receipt number, and to automatically
insert data that was retrieved from the database; however, none of this information
was used particularly well, nor was it obvious to the user what was going on.
Example 2 aims to correct this and other deficiencies in the first example,
and make the experience a whole lot quicker, easier, and more understandable
for the user. The five tips below explain some of the changes that can be used
to turn a bad experience into a good one.

Tip #1: Tell Users Why They're Waiting

Remote scripting is not instantaneous. Regardless of the speed of your web
connection, communication time with an external source will vary. So, while
communication with a server occurs, it's imperative that you tell the user
why they're waiting. (The example PHP scripts
use sleep() calls to highlight the waiting periods that can be
caused by network traffic or other factors.)

Because remote scripting applications do not make calls using the normal browser
interface, the status bar--which normally notifies the user of transfer status
and activity--does not function as it normally does. Thus, we have to provide
feedback to the user ourselves.

In Example 2, while the receipt number is being verified, a label displays
next to the receipt number field to explain the wait.

Figure 1.

The label changes to indicate completion once the XMLHttpRequest connection
has finished.

Figure 2.

The status message is initialized just before the XMLHttpRequest connection,
when the onchange event for the receipt number field is triggered:

Updating the message to indicate completion is important, as it provides closure
for the user. If the loading message simply disappeared, users could not be
certain that it had been successful.

In the two code samples above, the message function is a custom function that
dynamically creates a status label for a form element, and positions it visually
adjacent to the related element. It also accepts a class for the status label,
which allows CSS styles
to be applied differently for loading, error, and completion messages:

While the XMLHttpRequest process is running, the label animates to indicate
that the action is ongoing and still alive. In Example 2, this is performed
via CSS styling with an animated GIF, but it could also be effected using JavaScript animation.

The same feature is applied to the form submission button. Again, this alerts
the user that some action is being undertaken, and also lets them know that
they did click the button, which will help to discourage users from pressing
the button more than once:

Figure 3.

To achieve this, simply change the value and the CSS class of the submit button: