by Mark Schiefelbein
Ajax applications are praised for their richness, interactivity, and responsiveness, which are achieved by loading data dynamically using the XMLHttpRequest object instead of loading new pages. Among the hype and excitement, a few critical voices have pointed out that Ajax applications break several important browser features, including support for the back/forward button.
This article begins with an explanation of why the back/forward button and other browser functionality will not work unless explicitly built into an Ajax application. The article will then outline how developers can address these issues. Finally, we will look in detail at how the Backbase Ajax engine provides support for the back/forward button and other standard browser functionality.
The promise of Ajax is that it will allow developers to create visually attractive and highly interactive Web applications based solely on standard Web browser technology—often referred to as DHTML.
Developers previously had to choose between rich (an attractive user interface with a high degree of interactivity) and reach (a front end that works in any Web browser without additional client-side installations). Ajax applications should result in front ends that have both "rich" and "reach."
But what exactly does it mean for an interface to be "rich" and for an application to have "reach"?
The concept of "rich" is hard to define but easily recognized intuitively: You will know a rich interface when you see one. Desktop applications like Microsoft Office are rich. Rich interfaces use advanced UI controls like tabs and context menus. They provide advanced means of interaction such as drag-and-drop and highlighting of UI elements that have focus. Traditional browser applications are not rich. They are limited to simple controls such as forms, and interaction consists mainly of clicking links to new pages. Just look at Microsoft's e-mail clients to see the difference: Outlook is rich. Hotmail is not.
Ajax applications have been praised for their richness. Google's GMail is one of the most frequently cited examples. Other Ajax applications made by Google (Google Suggests, Google Maps), Microsoft's upcoming Web mail client, code-named "Kahuna," or the Backbase RSS Reader also contain advanced controls and interaction models. Look at Dan Grossman's list of Top 10 Ajax Applications for an impressive list of rich interfaces.
I would therefore argue that Ajax applications clearly satisfy the "rich" criteria. But what about "reach"?
In its most basic form, an application has "reach" if its interface runs inside a Web browser. Ajax applications are based on browser standards and therefore can be accessed from a Web browser.
However, being accessible from a Web browser is not enough. In his 2000 article Flash: 99% Bad, Jakob Nielson pointed out that Flash " breaks with the Web's fundamental interaction style." End users expect a certain interaction style when using Web applications. Applications need to comply with the traditional interaction style of the Web and provide the following usability features:
A look at the list of Top 10 Ajax Applications shows that most of the currently discussed Ajax applications do break the Web's fundamental interaction style. In the next section, I'll take a look at why many Ajax applications do.
The Web as we know it today is firmly rooted on the following three principles:
As a direct consequence of the changes in how to use (D)HTML and HTTP, Ajax applications break the back button and other elements of the Web's fundamental interaction style. In the remainder of this section, I explain how to fix this by handling URIs in an Ajax way. I'll first look at how URIs are related to user interaction in traditional Web applications.
User interaction in technical terms means a state change of the user interface. The end user initiates the state change. The browser client handles the state change by means of a page request to the server (REST principle). The server will generate the new interface state by sending a new page and a new URI to the client.
In summary, every user interaction is handled by means of a server roundtrip that results in:
The Web usability features are enabled because the browser records successive URIs in its history stack and shows the current URI to the end user in the address bar, where the user can copy it and send it to a friend. When the user clicks the back button or pastes a URI from an e-mail into the browser's address bar, a roundtrip to the server is triggered. As the server is responsible for state management, the server can generate the corresponding page.
In both cases, the state changes without generation of a new URI. Therefore, clicking the back or refresh button will have unexpected effects, and there is no deep-link URI in the address bar.
To provide the traditional Web usability features, the Ajax application therefore needs to handle URIs client side in much the same way as the server does in traditional Web applications. The Ajax application needs to:
With the above, the browser history will work, and the browser's address bar will show a URI that can be sent to a friend.
An additional difficulty is being able to determine when the Ajax engine should do the above (for example, which state changes should result in the creation of a new URI). In the traditional model every page refresh resulted in a URI update. In the Ajax model, every client-side event is a candidate for pushing a new URI onto the browser stack. Interaction designers and developers will have to make decisions as to which state changes are meaningful. URIs need to be generated for meaningful state changes only.
I'll summarize the client-side requirements for an Ajax application that provides Web usability features: