Usability Guidelines

Many usability experts have criticized AJAX by pointing out cases where it hurts usability. Although it is possible for AJAX to have that effect, I don't think AJAX inherently hurts usability; it's just that many developers have the wrong focus when adding AJAX to their sites. Focus on buzzwords and the latest technology results in nice demos but not necessarily in easy-to-use sites. Web development should always be user focused; adding AJAX to the mix shouldn't change that.

As you use AJAX, keep the following guidelines in mind, and you'll end up with a highly usable site or Web application:

• Keep the user's expectations in mind

• Provide feedback to actions

• Maintain the user's focus when adding content

• Keep the ability to undo actions

• Know if you are developing an application or a Web site

• Only use AJAX where it has the greatest effect

• Have a plan for those users without XMLHttpRequest

The following subsections cover each of the points in more detail.

Keep the User's Expectations in Mind

Keeping the user's expectations in mind is a broad guideline, but it is also an important one. At the simplest level, it means not changing how things operate without letting the user know. In most Web pages, buttons are used to submit forms, so having some other action, such as the clicking of a hyperlink, to submit a form can be confusing to users. This rule comes into play in any place where you redefine the standard way a Web site works.

One area in which you'll have a hard time meeting expectations is with bookmarking and the Back/Forward button operations; in many cases, these will no longer work, and you'll need new ways to support bookmarking within your application. This guideline doesn't mean that you have to change how the user interacts with your site; it just means that you need to work to provide the user with enough feedback so that he or she knows what is going on.

Provide Feedback to Actions

The next guideline focuses on providing feedback that an AJAX action has taken place. With this feedback, users know that some action has happenedeven if it doesn't work as expected. In a basic Web application, the page reload shows that something is happening. In an AJAX application, we remove the reload, so we need to replace this feedback. This feedback mechanism ranges from a loading message in the corner of the screen that is similar to the waving flag that Internet Explorer uses to visually highlight the sections of the page that have changed. In many cases, you'll want to use multiple approaches, such as showing a standard loading box while the new content is being transmitted and then highlighting the part of the page that was updated. Providing feedback keeps your application from feeling broken. When someone clicks a link, he or she expects something to change; without the feedback, it's easy to miss what happened.

Maintain the User's Focus When Adding Content

As you add feedback to your AJAX application, avoid disturbing the user's focus. This usability guideline is especially important when using popup messages; they should never be used except in areas where immediate action is required.

Here are some items to watch out for when thinking about maintaining a user's focus on one area:

• Actions that move the focus of a cursor. Such actions will cause the user to type in the wrong input box or have to take the time to figure out the current cursor location.

• Actions that cause page reflows. If a user fills out a form and an error message causes the form to move down half an inch, the effect can be disorienting.

• Distracting message styles. Blinking red text can steal the user's focus just as easily as a popup can.

As a user interacts with your site, remember that he or she controls the interaction, not you; if your message isn't important enough to require immediate action, don't push it into the user's focus prematurely.

Keep the Ability to Undo Actions

Many AJAX applications try to outthink their users by automatically saving data as needed or submitting a form without clicking a button. When this is done well, it can be effective, but you must keep the user's expectations in mind when applying these techniques. Users are used to a forgiving Web environment where they can simply reset a form if the current input is incorrect. As you add AJAX, you must keep that level of forgiveness; operations should always be undoable. Autosave is one of the worst offenders in this area, but it is easily fixable by adding a Reset button on an autosave form or exposing the history of the saves.

Know If You Are Developing an Application or a Web Site

As you develop with AJAX, it is important to know if you are creating an application or a Web site. If you are developing an application, focus on having it act like a native application; following the human-interface guidelines of the target operating system is often a good idea. If you are developing a Web site, strive to have your work fit the standard feel and interaction model. This focus helps set the user's expectations and will make your interface more learnable because the user will have a correct frame of reference against which to compare it.

Only Use AJAX Where It Has the Greatest Effect

AJAX is a powerful tool, but it should be only a part of your Web development arsenal. Always make sure not to overuse AJAX. It should be used in areas where its extra capabilities provide enough benefits to overcome its drawbacks. An example of such an area is the breaking of bookmarking within a page. AJAX is a great tool to update part of a pagejust load the changed contentbut it should not be used to load an entire page. Normal pages work just fine and are going to be just as fast as reloading the page with AJAX. When you are deciding on using AJAX, look for a problem that needs solving, not just for places where it might be possible to use AJAX.

Have a Plan for Those Users Without XMLHttpRequest

The last usability guideline is to have a plan for users whose browsers can't perform AJAX operations. No matter how usable an application is, if the user can't run it, it's useless. For internal applications, this is seldom an issue because a specific browser can be required, but that's not always a great idea for a mass market Web site. If you're using AJAX just to enhance slow tasks, an easy solution is to keep support for the slower non-AJAX operation. However, if much of your site depends on AJAX, you will need either to create a non-AJAX version or to keep non-AJAX users out of your site. Users who use browsers that don't support AJAX should always at least get messages that some actions won't work for them. As you add AJAX, make sure to understand your audience. Although AJAX is widely supported, it won't work in all browsers (especially mobile ones), and you don't want to lock out any part of your audience without addressing the consequences.

Read more...!

Defining Usability

Usability is defined by the International Organization for Standardization (ISO) in document 9241 as "the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use." For our purposes, this broad definition boils down to this: Can people easily understand and use your Web site?

Usability expert Jakob Nielson has a framework for looking at the usability of a Web site. It breaks down usability into five components: learnability, efficiency, memorability, errors, and satisfaction. By using this framework, we can identify usability problems in AJAX designs and identify ways to solve them:

• Learnability looks at how easy it is to accomplish tasks the first time the user visits the site. Learnability can be a problem in many AJAX designs because the site no longer acts like a standard Web site to which the user is accustomed. These problems are most common when the results of standard actions are changed. Creating new widgets can also be a problem, although this can be alleviated by making the new widgets look like their counterparts in the standard application world. Simplicity and consistency are keys to making an interface learnable. The goal isn't to make a flashy unique interface; it's to create one that new users can instantly recognize.

• Efficiency refers to how quickly the user can perform a task once it has been learned. This component sometimes stands in juxtaposition against learnability because the most efficient interfaces may require a large amount of knowledge to use. (A text-based data entry system is one example of an efficient interface.) Efficiency is the area of usability where AJAX can make a huge difference. AJAX can combine multistep processes into one quick screen to greatly reduce the time required to complete a task. This savings is most obvious in item-selection cases where multistep popup search screens can be replaced with search-as-you-type AJAX widgets.

• Memorability looks at how easily a user can regain proficiency in the use of the interface after not using it for a period of time. In such situations, the use of AJAX might not have a large effect, but it still can make a difference. AJAX can be used to streamline processes, which reduces the amount of steps that the user has to remember. It can also be used to create unique interface widgets that may hurt memorability because the user has no points of reference for them.

• The errors component focuses on having a system with few errors. It also focuses on how easy it is to recover from errors that are received. Web development as a whole is prone to network-related errors, but these errors are seldom fatal because users can just reload their browsers. In an AJAX application, network errors will need to be trapped in application code because the browser's Reload button won't resend the AJAX action. The greater use of JavaScript can also create more errors if developers aren't used to the language. One way to help alleviate these problems is to use an AJAX library that simplifies cross-browser development.

• The final component is a subjective measurement of satisfaction. Does the user enjoy using the design? This component is affected by many items, especially visual design, but AJAX can still play a part. A highly efficient AJAX interface that provides good feedback about what it's doing will be more satisfying than a standard, slow Web interface that requires tons of page reloads.

Read more...!

Promises and Problems of Combining AJAX with Other New Technologies

As you work with AJAX, you may hear of related technologies that you can use with AJAX. They fit into two main groups: mature technologies that are widely available in many browsers today, and new technologies that are available only on a specific browser. The mature technologies include Java and Flash. (Flash is the most important because its plug-in is widely installed, and its design is optimized for providing interactive elements and animations to Web sites.) Java can also be used to add interactivity to sites, but its popularity has waned over the past five years, and it's no longer installed by default everywhere.

Combining AJAX with Flash
Flash makes a good partner with other AJAX techniques because it provides a number of features that are not available with pure JavaScript. These include a canvas on which images can be added and positioned and a drawing API that can be used for creating graphics. In addition, Flash has the ability to stream video and sound, and it includes support for vector animations. The biggest drawback of Flash is that it adds a new, separate development environment, and although you can make calls between the JavaScript on your page and the ActionScript of your Flash movie, it's not tightly integrated with the rest of your page. Flash also has a different look than the rest of the elements on an HTML page, which makes it hard to deliver a consistent feel and operation when using it for small elements within a bigger picture.

The drawbacks of Flashpoor JavaScript integration and a different look and feelare not insurmountable, but they do lead many people to pick a complete Flash solution when they need to do anything complicated. This helps control complexity, but it leaves you fully tied to a single vendor and means that you have to use Flash remoting for your communications layer instead of AJAX. Adding Flash to your AJAX application gives you the ability to support many graphical tasks that would be impossible without it, but be prepared for a more complex design and debugging process.

Scalable Vector Graphics (SVG)
The new technologies in the browser world are not as widely deployed as Flash, and some, like Microsoft's Extensible Application Markup Language (XAML), have had only beta releases. They do have the benefit of being fully integrated into the browser, making them fully scriptable with JavaScript and available as first-class elements on Web pages. Scalable Vector Graphics (SVG) is a new W3C standardized language for creating vector graphics. It has many of the same features as Flash, allowing for animations and interactive graphical elements to be added to the page. SVG avoids many of Flash's problems because it uses JavaScript for scripting; in addition, it can be embedded directly into an HTML page and modified just like any other element.

SVG's biggest problem is that browser support has been slow to develop; a plug-in from Adobe currently supports many of its features, but it leaves some of the same integration problems as Flash. The next versions of both Firefox and Opera browsers will have built-in support for SVG, but that still leaves it as a niche technology that can be used only on internal projects.

SVG is also missing a canvas element, so there is no way for users to draw on elements, as can be done with Flash. To address this, a bitmap canvas was created by Apple for its Safari browser. This effort has since been codified by the Web Hypertext Application Technology Working Group (WHATWG). This group is supported by many browser developers, including Mozilla and Opera, so support will be forthcoming in new releases of these browsers; however, support by Internet Explorer seems less certain.

XML User Interface Languages
Many of the new technologies are missing widespread browser support, and XML-based user interface languages are no exception. These languages, which include Mozilla's XML User Interface Language (XUL) and XAML, add the ability to describe normal application elements (such as menus, scrollbars, text boxes, and buttons) in an easy-to-use XML markup. Microsoft and Mozilla built their XML languages to allow for the creation of highly interactive rich applications that look and feel much like native applications right out of the box. However, because they are supported only by a single vendor, they do create problems of lock-in and tie you to a specific browser. This lock-in makes for a much less compelling solution than widely compatible solutions built on top of JavaScript and HTML.

XUL was created to define the user interface of Mozilla's browser and has been available for a number of years. Recently, it has begun to gain momentum as Firefox has increased in popularity, but it will never be able to move beyond niche products until other browsers support the language. XAML was created by Microsoft as part of its .NET effort, and it is scheduled to be released as part of Windows Vista. It's hard to know what its effect will be until it's widely released and until we know how accessible it will be to Web developers.

The rise of popular new Web browsers has led to the creation of exciting new Web technologies. The biggest problem is that most haven't made it beyond being implemented in a single browser. As support for these new technologies increases, they may become larger players, adding in the technology needed to increase interactivity beyond the level that AJAX and dynamic HTML (DHTML) can reach on their own.

Read more...!

Measuring Improvements

Measuring the time it takes to complete a task is one of the most useful metrics when looking at the success of an AJAX implementation. The actual measurement process is broken down into three simple steps:

1. Identifying a task's starting and ending points

2. Adding instrumentation to measure the starting and ending times

3. Combining multiple data points into useful information

Deciding which tasks to measure is generally a simple process; you need only find the areas in the application about which users always complain. If a process is slow and clunky, it's a good target for AJAX and therefore a good target for measurement. After choosing the task you need to measure, identify its starting and ending points. It's important that you measure the entire process. You don't want to focus on page loads or the technical pieces, but actual steps taken by the user. If the process is complex, you may find it useful to watch users in action to see how things are actually done.

Once you've identified the start and end points, you need to add instrumentation. In most cases, you can do this by making some simple AJAX requests to a recording script. One call marks the beginning of the process, and a second records the ending. In our example case, we'll be recording the time it takes to select a user to edit, as shown in Figure 5-5. This example is extremely artificial, but useful, because the goal is to show how to instrument a process, not how to build an AJAX user editor.

Selecting a user

The breakdown of this task is as follows: Load the page, search for a user, and then select the user from the results. The start of this task could be considered the loading of the page or the clicking of the Search for User button. In our example, we use the clicking of the Search for User button because it will help reduce the amount of variance in our measurement. The end of the process occurs when the selectUser JavaScript function runs; in an actual implementation, this would either redirect us to a user editor or populate an editing form below the selection section. A unique ID will also need to be created so that the start and end times can be matched together, but as long as the client is making only one request at a time, this ID can be created and stored in our data-storing script.

To implement the instrumentation, we will be using our basic HttpClient XMLHttpRequest wrapper. We will be making an AJAX call to process.php at the beginning and the end of the process. process.php will store this data in the session, and then process.php's endProcess function will match it with a second end request that happens when the process is complete. A simple report (see Figure 5-6) can then be run to see how long each attempt to select a user took. The data storage is basic in this implementation and would need to be replaced with a database if you wanted to collect data from multiple machines.

The reusable parts of the measurement process are the process.php storage script shown in Listing 5-1 and the Monitor JavaScript class shown in Listing 5-2.

process.php

1  <?php
2  session_start();
3
4  if (!isset($_SESSION['data'])) {
5     $_SESSION['data'] = array();
6  }
7  if (!isset($_SESSION['id'])) {
8    $_SESSION['id'] = false;
9  }
10
11
12  function startProcess() {
13    if (!$_SESSION['id']) {
14      $now = time();
15      $id = uniqid('m');
16          $_SESSION['id'] = $id;
17      $_SESSION['data'][$id]['start'] = $now;
18      $_SESSION['data'][$id]['name'] = $_GET['process'];
19    }
20  }
21
22  function endProcess() {
23    $now = time();
24    $_SESSION['data'][$_SESSION['id']]['end'] = $now;
25    $_SESSION['id'] = false;
26  }
27
28  function printStats() {
29    echo "<table border=1><tr><th>Name</th><th>Start Time</th>
30      <th>Run   time (seconds)</th></tr>";
31    foreach($_SESSION['data'] as $process) {
32      echo "<tr><td>$process[name]</td><td>".
33        date('Y-m-d H:i:s',$process['start']) .
34        '</td><td>';
35      if (isset($process['end'])) {
36        echo ($process['end'] - $process['start']);
37      }
38      echo '</td></tr>';
39    }
40    echo "</table>";
41  }
42
43  switch($_GET['action']) {
44    case 'start':
45      startProcess();
46      break;
47    case 'end':
48      endProcess();
49      break;
50    case 'data':
51      printStats();
52      break;
53  }
54  ?>

Listing 5-1 uses a PHP session to store its data, so the script starts out by setting this up. We start the session on line 2 and then set some default values on lines 49. Lines 1241 define three functions, one for each of the actions the script can take. The startProcess function (lines 1220) first checks if we have a current ID stored in the session; this check allows us to ignore multiple start requests for the same process. If there isn't a stored ID, startProcess stores the current time, creates a new random ID, and then puts this data, along with the process name, into the session. The endProcess function (lines 2226) stores the current time as the end time and then clears out the ID to allow another process to start. These two functions provide the basic data-gathering capabilities of the script.

The third function, printStats (lines 2841), creates a table that provides basic reporting. It loops over the data stored in the session and creates an HTML table. While doing this, it uses the start and end times to calculate how long each process took. The output from this function is shown in Figure 5-6. Lines 4353 control which of the functions is called. The function to call is selected by the GET variable action. On the HTML side, JavaScript monitoring code makes AJAX requests to process.php to store the usage data.

simple report of how long attempts to select a user took

Monitor.js

1  // Class for monitoring time users spend performing actions
2
3  function Monitor() {
4     this.httpclient = new HttpClient();
5     this.httpclient.isAsync = true;
6     this.httpclient.callback = function() {};
7  }
8  Monitor.prototype = {
9     startProcess: function(name) {
10          this.httpclient.makeRequest(
11          'process.php?action=start&process='+name);
12    },
13    endProcess: function(name) {
14          this.httpclient.makeRequest(
15          'process.php?action=end&process='+name);
16    }
17 }

The monitor class is quite simple; it sets up an instance of HttpClient for asynchronous operation in its constructor (lines 37) and then defines two functions. The first startProcess sends a request to process.php, which triggers its startProcess function. The second function, endProcess (lines 1316), sends a similar request to process.php, but this time, the AJAX request triggers the matching endProcess PHP function. The main purpose of this class is to make it easier to instrument application pages, so it takes care of the boilerplate code for you. It is also a good place to add other methods if you find yourself needing to collect other data, such as which actions a user performs.

Now that we have a basic instrumentation framework set up to collect process times, we need to add it to a script. The process-time data can be useful in AJAX-driven pages to collect data that is generated by changes you are making. It is also useful in non-AJAX pages to help measure slow processes and to find ones that should be updated. Data collection like this can also be useful in making decisions on what data to prefetch, but normally, more data than simple timings is necessary because you need to identify which actions the user is most likely to perform. Listing 5-3 shows a simple user-selection script that uses the Monitor JavaScript class from Listing 5-2 to record how long each selection takes.

selectUser.class.php

1  <?php
2  /**
3   * This is an example class, which searches for a user from an array
4   * In most cases this class would actually query a database
5   */
6  class selectUser {
7
8     var $users = array(
9           1 => 'Joshua Eichorn',
10          2 => 'Travis Swicegood',
11          3 => 'Random Person 1',
12          4 => 'Random Person 2',
13          );
14
15    function search($input) {
16          $ret = array();
17
18          foreach($this->users as $key => $name) {
19                if (stristr($name,$input)) {
20                      $ret[$key] = $name;
21                }
22          }
23          return $ret;
24    }
25 }
26 ?>

The actual searching takes place in a related class, selectUser. This class does all its searching against an array to keep the example as simple as possible, but in most cases, this process would be database-driven. The class has a single method search (lines 1524), which takes an input. The method then case-insensitively checks this input to see if it exists in the array of any of the users stored in the class. Last, the method builds an array from the matching results and then returns this array. The HTML user interface is built in Listing 5-4, which uses the selectUser class to handle POST requests to the page.

selectUser.php

1  <html>
2  <head>
3     <title>Select User Non AJAX</title>
4
5
6  <script type="text/javascript" src="HttpClient.js"></script>
7  <script type="text/javascript" src="Monitor.js"></script>
8  <script type="text/javascript">
9  var monitor = new Monitor();
10  function selectUser(el) {
11     alert('Selected User with an id of: '+el.value);
12     monitor.endProcess('Select User');
13  }
14  </script>
15  </head>
16  <body>
17
18 <div id="HttpClientStatus"></div>
19
20 <h1>Select a User</h1>
21
22 <form action="selectUser.php" method='post'>
23    <input name="name" onclick="monitor.startProcess('Select User')">
24    <input type="submit" value="Search for User">
25 </form>
26
27 <?php
28 require_once 'selectUser.class.php';
29
30  if (isset($_POST['name']) && !empty($_POST['name'])) {
31    $users = new selectUser();
32    $results = $users->search($_POST['name']);
33
34    foreach($results as $key => $val) {
35      echo "<input type='radio' name='user' value='$key'".
36               "id='user_$key' onclick='selectUser(this)'>".
37        "<label for='user_$key'>$val</label><br>\n";
38    }
39  }
40?>

The script starts with some basic setup; then, line 6 includes the XMLHttpRequest wrapper, and line 7 includes the JavaScript Monitor class. Line 9 creates an instance of the Monitor class so that we can easily call startProcess and endProcess throughout the page. Lines 1013 define the JavaScript function that is called at the end of the user-selection process; this function just outputs a selected message and then runs endProcess. Lines 2025 provide the basic HTML UI of the page; this is a form that POSTs its results to the current page. The search input box runs a start process when you click it to start entering your search term.

Lines 2740 perform the search after the form is POSTed to the page. An instance of the selectUser class does the actual searching. The results from this search are then looped over, creating a radio button for each result. An onclick action is added to each radio button, which calls the selectUser function defined in lines 1013.

The basic workflow of this page is shown in Figure 5-7.

1. The user clicks the Search input box, sending a startProcess request.

2. The user clicks the Search for User button, POSTing the form.

3. The script uses the name sent in the POST request to build a list of radio buttons from which the user can select a specific user.

4. The user clicks a radio button, sending an endProcess request.

Workflow measuring how long it takes to select a user

Data collection is an important first step to making good decisions about how and when to implement AJAX. If the user-selection process is already fast, it doesn't make sense to spend time adding AJAX to it; instead, you'll want to find a different process to upgrade. If the process is slow, you can build an AJAX version that adds instrumentation to it and then obtain real numbers on how effective the process is. Ultimately, you may find that an AJAX version of the form won't give you the increased speed that you need, because searching by name doesn't scale to the number of users in your system; instead, your best results might be accomplished by limiting the search results using other criteria, such as department or job title.

Read more...!

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.

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.

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.

A standard table paging widget for a Web site, with each link causing a page reload

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.

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.

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.

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.

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.

Read more...!