Section 6.3. Usability on the Web

6.3. Usability on the Web

So far we've looked at the general principles and aspects of usability, as well the specific constraints and issues with the medium of the Web. Now it's time to synthesize that knowledge into some practical patterns for designing usable Ajax applications with Rails.

6.3.1. Know When to Use Ajaxand When Not To

Years ago, the choice of whether to Ajaxify an application was largely a question of resources: do you have the time and money required to wrestle with different browser implementations and quirks? Ajax has never been rocket science, but getting it right often required a significant amount of work. Rails changes that equation by making Ajax development just as easy as traditional development. Does that mean Ajax is the right tool for every job? Certainly not. Rails makes Ajax easy not so that you can always use it, but so that you can decide whether it's appropriate on the basis of the problem at hand. Upon discovering how to do Ajaxand how easy Rails makes itit's tempting to abuse it. Let's look at some examples. Don't break the back button

Perhaps the most fundamental rule of usable Ajax development is to not break the "back" button. Remember the role of expectations in usability: if users' expectations aren't met, the design isn't working. On the Web, practically nothing is more expected than the back button. It's an essential component of the Web user experienceand undermining it will lead to very frustrated users.

When we talk about the back button, it's really as a placeholder for the larger concept of address-barbased navigation. That is, users expect that the URL in the browser's address bar corresponds directly with the content displayed in the browser window. That enables a host of useful features: manually changing the URL to navigate the site's hierarchy, copying and pasting URLs into emails, creating bookmarks, viewing browser history, etc. The importance of URLs becomes immediately apparent when you try to tell someone how to find something in an overly Flash-driven site (e.g., "Go to this address, then click Skip Intro, then scroll down and click the link...").

All of the same problems can surface when Ajax is abused. XMLHttpRequest requests aren't logged in your browser's history, and they aren't reflected in the browser's address bar. Which leads us to a more fundamental rule of Ajax: don't use it for navigation. Don't use Ajax for navigation

This is a simple rule of thumb to avoid all kinds of Ajax abuse: don't use it for navigation. But what constitutes navigation? Adding an item to a to-do list? Flagging a message for follow-up? It might be a judgment call, so think critically about each case. Does an Ajax call result in most of the page's content changing? Then you're probably using it for navigation. If you are able to hit Reload and the page's essential content remains unchanged, you're probably safe.

On the other hand, what good is a rule without an exception? Take an application like Google Maps. Its central feature is a draggable map that fills most of the page. With one swipe of the mouse, you can "drag" halfway around the world. Because Ajax is used to update the map, the URL remains unchanged, which often catches users by surprise when they try to bookmark their location. And because it feels like navigation, there is a reasonable expectation that the back button would return you to the last location on the mapand yet it doesn't. In this case, the clear advantages of Ajax-based navigation must be weighed against the downside.

6.3.2. Keep Page Elements Consistent

Pre-Ajax, web developers generally had the luxury of atomic pageseach page self-contained and self-consistent. Adding Ajax to the equation gives the developer new responsibility for ensuring that all elements on the page stay consistent.

For example, suppose you are developing an email application, and the number of unread messages is displayed at the top of the page and in the window's title bar. If you use Ajax to update the inbox, all of those page elements need to be kept consistent. RJS makes it easy to update multiple page elements in one fell swoop:

page[:inbox].reload page[:unread_count].replace_html @unread_count new_title = "Inbox: " + pluralize(@unread_count, 'unread') page.assign 'document.title', new_title

This example uses RJS to update three page elements at once: first, reloading the inbox element with the contents of a partial; then updating the contents of the unread_count element with some new text; and finally changing the title of the document, which changes what's shown in the window's title bar.

6.3.3. Key Commands

Key commands don't usually make an interface more intuitive for beginners. But if your application is going to be used often by the same users, key commands can provide a huge advantage for power users, especially if it is heavily input-oriented. So key commands make sense in a webmail program, but probably not in a shopping cart. Most users don't expect web applications to have key commands, so you may have to go out of your way to make it obvious.

Prototype provides powerful tools for dealing with JavaScript events, such as key press events. For example, the following JavaScript can be used to add a few simple key commands to your application:

Event.observe(document, 'keypress', keypress_handler); function keypress_handler(event) {   switch(event.keyCode) {     case Event.KEY_TAB:    alert('Tab Pressed');     case Event.KEY_RETURN: alert('Return Pressed');     default: switch(String.fromCharCode(event.keyCode)) {       case 'A':            alert('A Pressed');       case 'B':            alert('B Pressed');     }   } }

Prototype's Event.observe method is detailed in Chapter 10.

6.3.4. Increasing Responsiveness with Ajax ('It's Too Slow!')

One of the primary reasons to enhance a web application with Ajax is to increase its speed and responsiveness. Note that speed and responsiveness aren't exactly the same concept; responsiveness creates the perception of speed.

In many cases, Ajax can significantly improve the absolute speed of a request by reducing the overhead of network traffic and browser rendering time. But in almost every case, Ajax techniques can improve the perceived speed of an action by providing activity indicators immediately.

For example, imagine a shopping cart application. The final "Submit Order" action might take some time to execute because the server must authorize the transaction with a payment processor. If the user feels that the request is stalled, his first reaction might be to click the submit button againopening the possibility of a double charge. Of course, the server-side code should have some means of detecting duplicate submissions, but you can also address the problem at the root: provide the user with an immediate visual indicator. For example, you might disable the submit button as soon as it's clicked, so the purchase can't be submitted twice.

6.3.5. Consequences of Increased Responsiveness ('It's Too Fast!')

Although you're unlikely to actually hear a user complain that an application is too fast, there may be some truth to it. Oddly, introducing Ajax to an application will often cause a most surprising usability issue: things moving too fast.

One of the expectations that people have of the Web is that it's slow. They know that after clicking, they can expect to wait at least a second for the page to change. Ajax can break that expectation, leading users to assume that the application isn't working, because they aren't seeing the usual time-consuming feedback of loading a web page: the address bar changing, an animated icon, and a brief blank screen. Remember the cardinal rule of usability design: if it works differently than the user expects it to, it's broken. The solution is to train your users to recognize that it is working by providing immediate visual feedback, reassuring the user that it worked.

For practical examples of loading indicators, see the Gallery and Intranet example applications. Free activity indicator graphics are available from

6.3.6. Blank Slates, Coach Content, and Help Nuggets

In manyperhaps mostweb applications, user-created data is the focal point of the application, and most of the UI elements exist in relation to that data. Content management systems, customer relationship management systems, wiki applications, and forums are all prime examples of applications where user-created content provides the skeleton for the UI to hang on.

Of course, while you are designing and developing your application, it's overflowing with test data in every possible spot, which is how users will experience the app after it's been "lived in" for a while. But when a new user creates an account for the first time, the view will be remarkably different: she'll see a blank slatean intimidating mass of white. Blank slates

As in personal relationships, first impressions are vitally importantand you may only have a few seconds to capture a user's interest before she reaches for the back button. The easiest, most efficient, highest-bandwidth way to learn about a UI is simply to look at itcertainly far easier than reading a few paragraphs of exposition. That's why planning for the blank slate case is so important.

There are a variety of approaches to the blank slate problem, but the easiest is to simply provide a graphic showing what the UI would look like if it was full of data. For example, I worked on a web application used to create and manage invoices. After a user creates a new account, they are able to sign in but don't yet have any invoice entered. In the first version of the application, we simply had a blank slate (see Figure 6-2). It was obviously a missed opportunity to show the user what the application could do, so we added a large graphic to the page, where data would normally be.

Figure 6-2. Blinksale without a blank slate graphic hardly a strong first impression

It's trivially easy to employ this solution to the blank slate problem in the Rails view:

<%= image_tag 'blank_slate' unless @invoices.any? %>

With one simple line of code, Rails inspects the invoices collection created in the controller, and if it's empty, creates an HTML image tag using blank_slate.png. Figure 6-3 shows Blinksale with a "blank slate" graphic. It's much more user-friendly.

Figure 6-3. Blinksale with a blank slate graphic is more inviting and educational Coach content

Some types of applications can go a step further. Rather than providing a static image of content, they provide coach content: starter data that's pre-loaded. For example, the RSS reader NetNewsWire provides every new account with a few subscriptions already configured, so that new users can see immediately how it worksbefore they even figure out how to subscribe to a feed.

Most wiki software also tends to include coach content. Typically, the interface for adding a page is little more than a large text box, but wiki creators include default text in the form to explain how wiki works, and they give examples links and basic formatting options.

Default values for form fields can be useful in other ways as well. Suppose you are designing an interface to create a note with a required title. Instead of leaving the title field blank, consider providing a default such as "Untitled Note." The default serves two goals at once: it educates the user about the field's purpose and also diminishes the possibility that the user will see a validation error because of leaving the field blank.

In Rails, setting a form field's default is as simple as setting the default value for a database column. If your form uses the standard ActiveRecord form helpers, the default will be automatically detected and used.

A word of caution about coach content: don't attempt to cover every nuance of your application with coach content: just provide simple, minimal examples that lead the user in the right direction. If your UI isn't well designed in the first place, this is not a good way to make up for it. Help nuggets

Another tool for guiding new users through an application is a help nugget: a small chunk of text to introduce and invite the user to try a particular feature, thus enabling discoverability. Help nuggets are highly focusedthey should only describe one small piece of functionality, in just one or two sentences. As soon as the user has used the feature once, the help nugget should disappear foreverits only purpose is to gently draw the user's attention to a feature he might not otherwise notice. It's generally a good idea to provide some sort of "dismiss forever" link in each help nugget as well. The goal is not to completely replace a help area for when more experienced users get stuck, but to provide a small boost over the initial hurdle.

For example, many Web 2.0 applications provide tagging, which enables users to organize content by means of ad hoc keywords, rather than predefined hierarchical categories. It can be a powerful feature, but many users aren't familiar with the idea. To encourage the user to try it out, a help nugget next to the tags UI might say something like:

"Use tags (like 'ajax, rails, usability') to organize your posts. [Dismiss this]."

Ajax on Rails
Ajax on Rails
ISBN: 0596527446
EAN: 2147483647
Year: 2006
Pages: 103
Authors: Scott Raymond

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: