Chapter 6. Usability Guidelines
In this chapter
▪ 6.3 Common Usability Problems
As shown in previous chapters, AJAX offers an exciting new set of possibilities, but it also creates new challenges. A big part of those challenges is creating a new interaction model that works not only from a technology standpoint, but also from the users’ perspective. Your new designs need to work and to be easy to discover. In addition, they need to allow for productive, regular use. This chapter looks at usability, provides a set of principles that help you create highly usable interfaces, and shows real examples to illustrate some common mistakes and ways to avoid them.
6.1 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.
6.2 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.
6.2.1 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.
6.2.2 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 happened—even 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.
6.2.3 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.
6.2.4 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.
6.2.5 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.
6.2.6 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 page—just load the changed content—but 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.
6.2.7 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.
6.3 Common Usability Problems
Although AJAX has the ability to create a more usable and efficient interface, it doesn’t always achieve this goal. Usability problems can steal away any gains created from the use of new technology. This section discusses some common usability problems and then gives examples on how to fix them. Many of these problems can happen without the help of AJAX, but they are prevalent in AJAX applications, which are more active by nature.
6.3.1 Stealing Focus with Validation Messages
A common use of AJAX is to perform complex validation before the user has submitted a form. This is especially useful on large forms where large amounts of data are input before validation can take place. Simplistic attempts at continuous validation are often worse than waiting until the form is submitted to perform the validation, because they continuously steal the user’s focus.
Figure 6-1 contains a basic registration form. AJAX is used to validate that the username hasn’t already been taken and that the zip code matches the city/state information. The problem here is that validation steals the user’s focus because it uses popup alerts to give validation errors as the user tabs to the next field.
Figure 6-1. A validation message stealing focus on a user registration page
One solution to this problem is to change from a popup error message to an inline one. In some cases, this is an acceptable solution, but it still causes problems. (In this case, the problem is that the more useful error message will cause the form to move down quite a bit in the user’s view.) Although usable, this approach pushes most of the form off the user’s page after a couple error messages are shown. It’s also not clear which fields need to be updated. Figure 6-2 shows an inline validation message.
Figure 6-2. A validation message that pushes the rest of the form down
Figure 6-3 shows a possible solution to these problems. The size of the error messages was reduced to a single line, and the use of a “More Info” link now provides information on how to solve the error. The fields with errors were also highlighted to show what needed to be updated.
Figure 6-3. Validation messages with the usability problems fixed
Stealing focus problems often happen when trying to meet the guideline of providing user feedback. Although user feedback is important, it should not prevent the user from completing his or her current task. This is especially important when feedback is combined with automatic actions, because the user has no reason to expect the feedback to happen.
6.3.2 Preventing Undo with Autosave
In conventional Web applications, large forms can be dangerous because they are impossible to save automatically, and submitting the form on a regular basis depends on the user clicking a button. Plus, such saving interrupts the user’s workflow. Here’s an example: A content management system was upgraded with AJAX to save an article automatically every five minutes. This seemed like a great solution because then only five minutes of work could be lost by a browser crash or an accidental closing; however, after more use, a couple of problems with this approach were found.
One problem occurred when an author opened an article to edit it. He or she would make some changes and then decide, perhaps, that he or she didn’t like the approach taken. In other words, the author ended up wanting to revert to the old version, but couldn’t; during the editing process, the autosave process had already overwritten the original. This was not good.
As you can see from the previous scenario, editing couldn’t be done on live articles because the autosave process would push out changes before they were complete. This problem can be solved easily by creating a separate autosave area to store the data from this process. This autosave area can keep anywhere from one to an unlimited number of autosaves. An interface is then added to let users load an autosave and save it as a normal version.
In some content management systems, documents are versioned so that the original problem of overwriting data doesn’t happen. However, saving each autosave as a new version can also be problematic because it makes for a clumsy document history and can cause data-storage needs to explode. In a versioned content management system, a separate autosave area would also work, but it may be more useful to use a subtree in your version history to which autosaves are written. The application can then remove the old autosaves when each normal save is complete. This allows autosaved articles to be accessed by the normal article-management process without causing an explosion in version history.
Preventing undo operations often happens when AJAX implements autosave. This prevention results in data-loss situations from a process that was supposed to prevent them. Whether you are using time-based saving while editing an article or autosaving a form by detecting what field is edited, you are changing the way a Web form normally operates. Because you are moving the save decisions out of the user’s hands, you need to provide a way for the user to revert his or her changes.
6.3.3 Updating Sections of a Page Without the User Realizing It
One way to use AJAX is to update parts of the page with new content in response to a user’s action. This AJAX updating process could be used in technical documentation to load definitions or related information. A basic example of this is shown in Figure 6-4. When you click any term with a dashed link, its definition is loaded into the sidebar on the right.
Figure 6-4. Documentation Browser with no feedback
The page in the preceding figure is already taking some usability steps, such as using a different link style for definition links, but it still has one problem: No feedback is given to the user regarding the fact that something has changed. Feedback is important in this case because we are redefining a standard browser action. Normally, when you click a link, it loads a new page. If the user were expecting a new page to load and didn’t notice the change on the right, he or she might think the link was just broken.
Providing feedback is about finding the right balance; we want to show that something has changed without annoying the user with effects that are overly flashy and distracting. There are a number of different techniques we can use in this case. One technique is to show a loading message while the browser is waiting for the server to respond. At this same time, we can fade out the current content and then fade it back in after the new content has arrived. Figure 6-5 shows this approach in progress.
Figure 6-5. Documentation Browser while loading new content
An alternative to providing loading feedback is to wait until the new content is loaded and then highlight it in a pale yellow background. Over a period of three to five seconds, this yellow then fades to the white background color. Figure 6-6 shows the beginning of this process. In a documentation browser, I would recommend this approach because it doesn’t distract the user until there is actually something to see. However, in another application where the content may take a while to load, immediate feedback would also be needed. You could combine both approaches, but in most cases, a more subtle approach is just as effective and is more aesthetically pleasing.
Figure 6-6. Highlighting content to provide feedback that the content has been updated
6.3.4 Breaking Bookmarking by Using AJAX to Load Entire Pages
Many times, when developers adopt a new technology, they see it as the solution to every problem they have. One area where AJAX can be overused is as a replacement for HTML framesets. This AJAX usage allows you to skip the loading of the navigation sections and just update the main body of the document. However, unless you take steps to make bookmarking work, you have the same problems as using frames—plus a more complicated development process. Figure 6-7 shows an example of this mistake; here, everything below the navigation bar is loaded using AJAX.
Figure 6-7. Loading an entire page using AJAX
In most of these cases, the simple solution is to use only normal pages; because navigation is seldom a large part of a page’s loading time, these approaches save little in load times. In other cases, you may find that trying to load entire pages using AJAX is just a symptom of larger design issues, and you’ll need to start at the beginning and focus on how users will interact with your information. AJAX is a great tool, but it is not the solution to every problem. Design and development should always keep the user in mind. The end result might not use every technology you would like, but it will make for the best user experience.
6.3.5 Making AJAX Required on a Web Store
Although AJAX adds great capabilities to a Web site, it’s not always worth the cost. The biggest cost is preventing users from using a site because they’re not using an advanced-enough Web browser. While it’s easy to say “Please upgrade,” doing so is not always possible, especially if the user is using a mobile device, such as a PDA or cell phone. Let’s look at a fictional scenario to see some of the problems that might be caused by requiring AJAX. A Web-based store updated its shopping cart to use AJAX; it then tested AJAX on all the major browsers, and everything worked fine. Because the store was supporting all major browsers, it decided to drop its non-AJAX version. After rolling out the new shopping cart, a large number of complaints came into the company’s support email. After some research, the store noticed that all the complaints were from users using Pocket IE on smart phones or PDAs.
This is a fictional example, but it shows important points. Although no new computer will come with a browser that can’t be used with AJAX, lots of mobile devices still will. If your site has a broad user base, requiring AJAX may shut out a sizable part of your audience.
6.4 Summary
AJAX can create great interfaces that have much higher usability than current Web development techniques. However, using AJAX doesn’t guarantee that the end result will be highly usable. Usability requires the solid presence of many different aspects of the user interface. AJAX has the ability help some aspects, but it has a tendency to hurt others. This chapter’s usability guidelines can help keep you on the right track. While developing with AJAX, remember the following:
• Think about the user’s expectations
• Provide feedback when performing actions
• Avoid breaking the user’s focus
• Give the user the ability to undo every action
• Follow the style of a Web site or an application, not a mixture of both
• Use AJAX to improve usability, not to add new technology
• Plan for users whose browsers don’t support XMLHttpRequest
AJAX can help you to produce great applications that use the latest technology and to perform tasks you didn’t think were possible. However, there is more to success than implementation. An AJAX application is compared not only to other Web applications, but also to native applications. This comparison raises the bar higher, because we’re moving into a more mature development space. A highly capable site with poor usability is no success; great development has usability as a major focus and offers the new features in a highly usable package.