Section 5.1. Goals of AJAX

5.1. Goals of AJAX

First and foremost, AJAX is about improving user experience; user experience improvements fall into two categories: making current tasks easier and making previously impossible tasks possible. Obviously, it is easier to focus on making current tasks easier. In Web development environments, this can be further broken down into two main goals: increasing interactivity and decreasing the time required to perform a task. In nonintranet cases, you may also have a related technical goal of reducing bandwidth use; by transferring less data to the browser, you can reduce page load times and improve the user's overall experience.

5.1.1. Increasing Interactivity

One of the overall goals of adding any amount of JavaScript to a Web site is to increase its interactivity. Even without AJAX, you can provide content-sensitive information when the user moves over a link or validates a form without reloading the page. This extra interactivity provides more information to the users without overwhelming them. Using AJAX, we can build on this general process instead of focusing on adding extra static information; in other words, we can add extra information dynamically.

A good example of increasing interactivity is using AJAX to add a real-time search to a normal search form on your Web site. An example of real-time search is the Google Suggest application (www.google.com/webhp?complete=1&hl=en), which suggests possible search terms in a drop-down widget as you type your query; the widget would also indicate the number of results the search would return. Using Google Suggest to search for AJAX is shown Figure 5-1. Similar approaches can be used for any search application. The possibilities range from selecting a user on which to change permissions to picking a city to which to send a package.

Figure 5-1. Using Google Suggest to search for AJAX

You can also use AJAX to increase interactivity in ways other than search methods. One way is to use a scrollbar to move through a page of results instead of using the Web method of next page links. AJAX works well for items such as these because data is still loaded only as needed, just as with a normal table, but the later rows can be accessed much more quickly. Figure 5-2 shows a standard table paging widget, whereas Figure 5-3 shows a table using an AJAX scrollbar instead. The example in Figure 5-3 also allows columns to be sorted without loading the page. AJAX-based filtering could also be added to the table, making for a quick and natural data-browsing experience.

Figure 5-2. A standard table paging widget for a Web site, with each link causing a page reload

Figure 5-3. AJAX-based scroll table with new data being loaded by moving the scroll bar

AJAX opens up lots of new ways to increase interactivity because the extra data you're showing can be loaded as needed. This becomes especially useful when working with medium-sized data sets, because you can see all the data without increasing the original page-load time or needing another reload to see the data. The biggest problem with increasing interactivity is that it is hard to measure, so increasing interactivity becomes most useful when looked at when addressing our secondary goaldecreasing the time required to perform the actions.

5.1.2. Decreasing the Time Required to Perform Actions

One of the biggest disadvantages of Web applications is that any multistep process becomes a multiminute process. On a fast connection, each page-reload connection adds two to five seconds of pure wait time as the next page is generated and downloaded by the browser, and on a slow connection, the waits can be double or triple that. Using AJAX to load in the new data allows us to remove these page reloads, making for a seamless experience with only a small one- or two-second wait for extra data.

There are lots of other cases where AJAX can be used to decease process times. They include using multistep wizards and reviewing and updating online content. Once you've found a task that takes a long time, such as moderating posts on a customer support forum, you look for the specific subtasks that take up the most time. In forum moderation, the problem is that each page reload takes a long time because you may be looking at 20 or 100 posts at once. Moderating posts requires one reload to start editing and then one reload to save your edita painful process. Other tasks, such as moving a post, are also slow because each page reload can make you lose your place in the list of posts.

For example, consider a conference-room booking system at a large company. After a room is chosen, each participant needs to be searched for and added to the booking so that he or she can receive a notification email. Because the company has over 100 employees, a select drop-down widget isn't a good choice. Using it would greatly increase page load times because so much data would need to be preloaded. An extremely large drop-down widget would also be unwieldy to use.

The solution to this selection problem prior to AJAX was to add a search system to find each employee; the search system might even be put in a popup window to lower the amount of data to be reloaded, but no matter how it is implemented, adding each person becomes a 5- to 30-second process. This clunky interface isn't a problem when adding 1 or 2 people, but it becomes unbearable when adding 20 or more. An AJAX approach allows the search to happen using a real-time search. The interface would look much like Google Suggest in Figure 5-1, displaying employees' names instead of search terms. In this case, by using AJAX, we make adding 20 employees a 1-minute process instead of a 5-minute process.

Using AJAX, you speed up the process by adding in-place editing and by using drag-and-drop to move a post. In-place editing works by creating a text editing box without reloading the page. Because the content is already displayed, no request needs to be sent to the server to start an edit. At the end of the process, the changes are transparently saved while the user moves on to editing the next post. An example of using inline editing is shown in Figure 5-4. Drag-and-drop moving of posts is also a large time-saver, mainly because it's much easier to see the target location on your normal post-browsing screen than it is to see it in a list of post titles that a non-AJAX process would be forced to use.

Figure 5-4. In-place editing

One of the things that make reducing task time such a great AJAX implementation goal is that it is easily measurable. All you need to do is sit down and perform some of the tasks and track the amount of time they take to complete. Depending on the tasks, you can even add timers to the application to record normal-use data. Once you have these baseline numbers, you can create specific targets for your AJAX implementation. Combined with further tracking after you've created an AJAX implementation, you can obtain data to decide how effective your enhancements have been. With a real and repeatable measurement, the effectiveness of AJAX moves from guesswork to simple math. You can even use this process-time measurement to improve on your current AJAX use, swapping out techniques or adding in prefetching to make a process take less time.

5.1.3. Reducing Bandwidth Use

Reducing bandwidth use can be a useful goal in some AJAX implementations because a smaller amount of data takes less time to transfer, providing the user a more seamless experience. If you're paying for hosting, reducing bandwidth use can also be an effective way to save money. However, if you're using your application on an internal network, this may be a goal that doesn't matter at all because the fast network keeps load times low no matter how much data you transfer.

Bandwidth use is easy to measure; the related metrics are always easier to use than subjective comparisons. Of course, unlike the measurement of time to perform a task, bandwidth use isn't a number that you always want to see decrease as a whole. Reducing the amount of data loaded in the initial page load can be useful, especially if that data is seldom used and can be easily loaded as needed. However, in some cases, the best user experience is achieved by preloading data and increasing the overall bandwidth use.

You can preload data directly during the initial page load or by using AJAX call, but you'll find that using AJAX is beneficial as long as the data isn't needed immediately. AJAX preloading can happen after the page is loaded, making it less noticeable to the user. It can also be tied to the beginning of a task that will use it. This is especially true when browsing large data sets because they generally have consistent access patterns that can be discerned by monitoring the users of the applications.

AJAX doesn't have guaranteed bandwidth reductions and, in some access patterns, it will likely use more bandwidth. This is especially true when you're performing event-driven AJAX requests. Each request may be small, but a search for each keystroke can quickly add up. These effects may be reduced by limiting the number of events to one per time period, but the effects will still build up over time. Your goal should be to make each request as small as possible, while realizing that these bandwidth reductions may be eaten up by the greater quantity of requests and by using prefetching to make a highly interactive interface.

5.1.4. Creating Rich Applications

Our first three goals focused mainly on making enhancements to current Web applications; however, AJAX also gives us the possibility to create an entirely new class of Web applications. When creating rich applications, developers have the goal of making them work as much like native applications as possible, while trying to keep Web development's advantages in ease of deployment and implementation. In addition, rich applications development still has the goal of increasing the interactivity of the application and decreasing the time needed to perform actions, although the design and implementation of these goals may be different.

Because you're not taking a current application and fixing slow spots, you don't have the baseline metric of a standard Web application. Instead, you have to compare your application against its native equivalent. This can be challenging because native applications can use large persistent data stores to reduce the number of slow interactions, whereas AJAX applications are limited to smaller session-based caches. Depending on how data-intensive the task is, you may be unable to match the performance of a native application, so you'll need to focus on different usage patterns that will hide this problem. The easiest native applications to mimic are those that deal with a large dataset that isn't stored fully on the local client; because the data-access speeds are similar, the Web application needs to compete only on the quality of its user interface.

Many rich applications use more bandwidth than their standard Web application counterparts because they rely heavily on prefetching data to give a seamless user experience. This makes rich applications better suited for internal deployments where a fast network and the lack of bandwidth charges remove bandwidth reduction as a necessary goal.

The decision to build a rich application instead of an enhanced Web site should not be taken lightly. Rich applications work best when they are targeting the tasks performed by a native application. Email clients, RSS readers, and reporting applications are good examples of native applications that are easy to mimic. That being said, services normally provided by Web sites, such as shopping at an online store or displaying product information, don't translate well to rich applications. These tasks are better suited to an enhanced Web site where only the slow, complex tasks are replaced with AJAX versions.