Asynchronous or remote scripting has been lurking in the background of web app development for quite some time now. Originally dependent on proprietary technology like Java applets, ActiveX and Flash or clever combinations of disparate technologies like images and cookies, native support for the XMLHttpRequest (XHR) object in modern browsers has made it easier than ever to make web apps more responsive and more like their desktop counterparts. This lower barrier to entry also makes it easier to make poor decisions and inappropriate use of a powerful technology.
So what’s a well-intentioned web developer to do? Stop and think about the following before dropping that sudsy, lemon-scented bomb on unsuspecting users.
Content or Action?
Using XHR circumvents the browser’s history. As a result asynchronous scripting is most appropriate for actions and transient or conditional data—not navigating content. XHR doesn’t break the back button, misunderstanding user expectation does.
Search results, tags, comments, and data validation are all good examples of transient data. All are given to flux and make perfect candidates for manipulation by AJAX or similar technologies.
On the other hand, avoid replacing traditional navigation with XHR. Doing so breaks an inherent functionality responsible for the success of the web: Universal Resource Locators. Unless we reinvent the wheel and restore this functionality ourselves (hidden iframes and fragment identifiers anyone?), it is impossible to link directly to content included with XHR.
Both HiDefDVD.com and Microsoft’s recently launched Windows Live Shopping make this laughable mistake. By relying on XHR for navigation and providing no alternative they effectively cede any search relevance to the market leader Amazon who appropriately uses the traditional navigation model (remember at the time of this writing search engines don’t parse JavaScript).
To avoid repeating a similar mistake, try this litmus test: If refreshing a page immediately after that page has been updated by remote scripting results in an essentially identical page then you’re doing okay. If not, head back to the drawing board.
Communicating Change
While not directly tied to asynchronous scripting, page content is often replaced unceremoniously in an application that uses XHR. Without the intermediary blank page followed by a browser’s built-in progress indicators informing users that something is happening, the responsibility now falls on the developer to inform the user of pending changes.
Spinners, hourglasses and progress bars build upon users’ experience with desktop applications and indicate that an operation is pending completion. When inserting or replacing content, animation and movement go a long way towards capturing attention and alerting the user that the page has been updated.
These purely visual techniques fall short when the modified content has been scrolled off screen (imagine using an AJAX-ified mobile app) or with a screen reader. Potential solutions to this shortcoming are still being explored but parallels already exist on the desktop. When a background application requires attention in Mac OS X, it may chirp and bounce the dock icon to alert the user. Keyboard shortcuts can be used to navigate to the needy application. Using access keys and audio triggered by an XHR callback function it is possible to mirror this behavior.
Progressive Enhancement
In DOM Scripting, Jeremy Keith coined the term “Hijax.” He suggests that we plan and develop using the traditional “links to GET/forms to POST” model without relying on JavaScript. Then we hijack those links and forms with asynchronous scripting calls using the onclick and onsubmit event handlers, allowing us to bypass intermediate screens and refine existing interaction.
This type of development favors using AHAH or AXAH over JSON or XML-based flavors of AJAX. By including the same HTML generating file that we plan to request using XHR, we keep our business logic out of the JavaScript and on the server where it belongs.
There are a number of JavaScript libraries out there that encapsulate XHR. When choosing a library or framework for our applications we need to be asking ourselves hard questions. A framework might make our lives as developers easier but will it also facilitate making bad decisions? When taking the Hijax approach we may notice that while XHR allows you to POST data to the server, when using an HTML link we don’t actually make use of this feature. Why? There is no analogous to POSTing with a link in the traditional model, that behavior requires an HTML form. We need to keep in mind that a library that allows us to do so allows us to make a mistake that could disable our application when XHR is not supported or JavaScript is disabled.
Once these ideas about AJAX soak in we’ll be producing clean web apps that play nice with search engines, desktop and mobile browsers, and web-enabled dish-washers alike.
Like this article? Digg it!
We're big fans of 
Sun, May 28, 2006
AJAX, Dev, Features