Developing Ajax Applications That Preserve Standard Browser Functionality

by Mark Schiefelbein
01/24/2006

Abstract

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.

Do Ajax Applications Require a Back Button?

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:

  • Back and forward buttons should work, allowing the end user to navigate through the page history.
  • Users should be able to create bookmarks.
  • Deep links should be provided that end users can send to friends and colleagues by e-mail.
  • The refresh button should work, refreshing the current state as opposed to re-initializing the application.
  • Developers should be able to see the source code using "view source."
  • End users should be able to search the page using "find."
  • Search engines should be able to index the page and create a deep link to search terms.

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.

Why Do Ajax Applications Frequently Break the Back Button?

The Web as we know it today is firmly rooted on the following three principles:

  • (D)HTML for defining the interface
  • HTTP for client-server communication
  • URIs for addressing

Ajax programming makes interfaces richer by pushing the limits of what can be achieved within the boundaries determined by the above principles. As explained in my previous article, A Backbase Ajax Front-end for J2EE Applications Ajax introduces extensive use of JavaScript (the "J") for the creation of rich UI controls and interaction. Ajax also introduces asynchronous XML communication (the "A" and "X") by means of the XMLHttpRequest object to load new data and presentation logic without a page refresh. The current Ajax model, however, does not address how to handle URIs.

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:

  • Generation of a new page
  • Generation of a new URI

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.

The major difference between Ajax applications and traditional Web applications is that Ajax applications can handle user interaction without page reloads. Loading data from the server through the XMLHttpRequest object is one example. Using JavaScript to handle drag-and-drop client side is another.

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:

  • Generate a URI and send it to the browser when a client-side state change occurs
  • Recreate state when a new URI is requested by the browser

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:

  1. Create history
    1. Save meaningful state
    2. Generate a corresponding URI
    3. Push the URI onto the browser stack
  2. Restore history
    1. Detect URI change
    2. Recreate the state from a URI

Pages: 1, 2, 3

Next Page »