any developers have adopted AJAX as a way to develop rich web applications that are almost as interactive and responsive as desktop applications. AJAX works by dividing the web UI into different segments. A user can perform an operation on one segment and then start working on other segments without waiting for the first operation to finish.
But AJAX has a major disadvantage; it breaks standard browser behavior, such as Back, Forward, and bookmarking support. Rather than forcing users to adapt to AJAX's shortcomings, developers should make their AJAX applications comply with the traditional web interaction style, providing the following usability features:
- Back and Forward buttons should work, allowing end users to navigate through the history pages in an intuitive manner.
- Users should be able to create bookmarks.
- The Refresh button should work as expected, refreshing the current state as opposed to reinitializing the application or an unexpected page or state.
- End users should be able to search pages using their browsers' standard search functions.
- Search engines should be able to index the pages in AJAX applications and create deep links to search terms.
Typical AJAX applications do not meet the first three usability features. Dynamic web applications that use AJAX technologies such as the XMLHttpRequest object and DOM updates do not update the browser history correctly, because retrieving data using a background request doesn't change the page URL. The outcome is that when users click the Back button, they are likely to jump all the way out of the web application, losing any saved state. Clicking the Refresh button reinitializes an AJAX application to the initial state of the current page (often effectively restarting the application). Bookmarks don't work for the same reason; using a bookmark to return to an AJAX URL might not reflect the page state at the time the user made the bookmark.
From a user's perspective, standard navigational conventions are quite important. People have come to expect certain interaction conventions when using web applications that typical AJAX applications lack. For example, when users try to bookmark a page using the browser's URI they lose any information about the intermediate steps (the background requests) that the AJAX application made to create that page. Similarly, when users click the browser's Back button they will be shown the previous page, which is usually not the previous page state. The difference between "page" and "page state" is critical in AJAX applications, because they're the same thing to users, but to browsers, they're completely different.
For example, suppose a person's using an AJAX-based search application. The first page contains a search form where users enter search criteria—call it Page1
. After submitting the filled-out form, the person sees a page containing the first few search results (Page2
), along with a pagination link to view the next set of search results on Page3
, and so on. The application retrieves the next set of search results for Page3
by sending an asynchronous call and populating the DOM structure of Page2
with the retrieved data. The page state has changed, but note that the URL of the page (still Page2
) has not; in other words, despite the fact that users think they're looking at a new page (Page3
) the browser's history stack for this application looks like this:
Therefore, when users click the Back button from Page3
, they logically expect
to see the first set of search results (the original Page2
); however, the browser will dutifully navigate back to Page1
instead. Similarly if they refresh the page while looking at Page3
they will see Page2 instead. This counterintuitive behavior confuses users and makes applications more difficult to use.
If each unique document created by an AJAX application could be addressed by its own URL, then you could conceptually solve the broken Back button and bookmarking problem. Notice that the search application references the first result page by one URL and the second page by a different URL; in other words, the two URLs each refer to different resource documents. In contrast, AJAX documents are built up from a starting document plus an arbitrary number of DOM manipulations that add, remove, and change the nodes in a document. Therefore, to recreate an AJAX document at any given point, you have to start by retrieving the starting document's URL, and then apply all the DOM changes made up to that point. That would be a lot simpler to do if each AJAX request had a unique URL.