To Refresh, or Not to Refresh

Ironically, removing page refreshes can make for a refreshingly interactive experience. However, eliminating the refresh doesn’t come for free. When is it worth the investment?

Amazon’s Helpful Reviews

Out of the 5,424 reviews listed on Amazon.com for J.K. Rowling’s Harry Potter and the Sorcerer’s Stone, it’s a July, 2002 review by Victoria Tarrani that the site displays first. That’s because 443 people have indicated this was a “helpful” review, out of the 533 who shared any opinion on the matter. Amazon bubbles the reviews voted most helpful to the top of the list, to prevent them from becoming buried by more recent reviews that are less useful.

A simple question at the bottom of each review asks the reader if they’ve found the review to be helpful. Those that feel inclined to respond can choose between two buttons, simply labeled Yes and No. While Amazon has sold millions of copies of this book since 2002, very few have shared their opinion of Ms. Tarrani’s review. However, the few that did have provided a valuable service to future Harry Potter shoppers.

The interesting part of the helpful buttons is they don’t refresh the page. Instead, upon pressing the button, a message appears, first informing the reader their feedback was being saved, then thanking them for their vote.

The Amazon team uses Ajax to complete this action. When the button is pressed, a message is sent to the Amazon server, who then confirms its receipt. Once the javascript function receives the confirmation, it displays the thank you note. All this happens in mere seconds, assuming the connection is solid. With practically no interruption, the user is now ready to go on to their next activity.

There are other ways Amazon could’ve implemented this same functionality. They could have, for example, stayed with the traditional button behavior, building the question into an HTML form tag. Pressing the button would do practically the same thing as the current Ajax behavior, except a new page would be returned.

From an implementation standpoint, the communication with the server is almost identical with this method. From the user’s standpoint, however, it would be dramatically different. The user couldn’t continue interacting with the page, until the new page was loaded. Returning the user to the same point in the page would be difficult, creating a jarring effect. (Anchor tags could get the browser to the same general neighborhood, but the page would likely shift from its original configuration.)

The designers at Amazon wanted to make the action subtle. Another option would’ve been to use radio buttons for each review. Clicking the radio button to indicate Yes or No wouldn’t invoke a page refresh. However, to register the vote, users would have to remember to press a submit button. It’s likely that users might forget to do this, thereby neglecting to get their votes registered, and defeating the purpose of the function.

For Amazon, Ajax is the right way to implement this functionality. However, deciding when to use Ajax to eliminate a page refresh is not always easy.

At Netflix, Ajax Pushes to the Top (Sometimes)

The designers for Netflix.com are big fans of using Ajax to eliminate page refreshes, having been a pioneer with the technique from the early days. (They were one of the first, using it to register how many stars their subscribers rated each movie.)

Interestingly, they don’t use it for everything. One place where this jumps out is in the movie queue. Subscribers add DVDs they’d like to watch to the queue and use it to manage the order they’ll receive the discs.

The queue functionality offers three ways to change the order of the list. In the early versions, subscribers entered a number into a type-in field next to the movie and pressed an update button. Putting a ‘2’ in the third movie would move it to the second position on the list.

Because the most common subscriber action was to choose the next movie to watch, the team added a “TOP” button to move the disc to the top of the list. In the most recent version, users can also drag the movie into the new position.

It’s interesting that the original number-and-button operation still results in a page refresh, while the new operations don’t. Similarly, on the same page, rating a movie doesn’t have a refresh, while deleting a movie from the list does.

This isn’t by accident—the designers have made these choices deliberately.

Comparing Orbitz and Kayak: Sorting Flights

Here’s an experiment you can try at home: Open up two browser windows (or tabs). In one, bring up the travel reservation site, Orbitz.com, and in the other, bring up it’s competitor, Kayak.com. Ask for the same reservation in each, say a 4-day trip from Boston (BOS) to Las Vegas (LAS) sometime in November. (Putting it a couple of months out will give you the most flight options.)

Both sites lets subscribers sort the resulting flight options by several criteria, such as price, departure time, and duration. This is what we’ll compare. Measure how long it takes to re-order the list when you switch to a different criteria.

When I do it, it takes Orbitz 6 to 7 seconds, on average, to make the switch, while Kayak is usually less than 2. Orbitz involves a page refresh, while Kayak reorganizes the data without the refresh. (Interestingly, Orbitz only loaded the page with data for 45 flights, whereas Kayak loaded the data for all 532 flights in my trip. The initial load for Kayak is a little longer, moving all that data, but not substantially so.)

How Much Does 2 Seconds Matter?

When we’ve watched users booking reservations, we’ve noticed users are far more likely to explore the sorting options on Kayak than on Orbitz. We think Orbitz’s design limits the interaction experience for users because of the page refresh.

Can the refresh be too fast? Absolutely. Kayak, interestingly, has to put up a big interstitial box that says “Sorting Results…” to ensure users notice. In earlier designs, when they didn’t display the box, users would often miss the re-ordering, thinking that nothing happened.

When to Eliminate the Refresh

If the result of the action will bring the user back to the same page, then it’s a good time to investigate eliminating the refresh. For example, instead of re-displaying the same account creation page after the user entered a password that isn’t good enough, using a javascript function to give feedback on the password immediately after entry can make for a nicer experience.

In most browsers, a refresh freezes the current page, waits for the new data, erases the old page, redraws the new page from the top, and, if specified, jumps to the anchor. The freezing and flashing result can be a jarring experience for the user. When the user is expecting a different page, they don’t seem to pay much attention to it. So, for most clicks, a new page will be what people expect.

However, as in the case of Amazon, Netflix, and Kayak, sometimes you want to go for a more subtle effect. Instead of the flash and bounce from a refresh, a simple changing of the data works better, encouraging the user to interact even more.

There are downsides, of course. Javascript and Ajax isn’t easy for everyone to work with. It has browser incompatibilities, so you have to be up-to-date on the latest hacks. Memory management in Javascript can get messy, causing performance problems as more data is loaded into the browser. (Google’s new Chrome browser is optimized to deal with this, since Google loves to use Ajax in its applications.)

You also need to ensure you degrade your experience nicely, in case the user’s browser doesn’t want to play nicely with javascript. For example, Amazon’s “helpful” prompt goes the plain-old buttons-with-refresh route if javascript is turned off. That means they have to implement everything several ways. (See Jeremy Keith’s article on progressive enhancement to learn more about tricks to doing this.)

Eliminating the refresh can make for a better experience. Knowing when to pull it out of our designer’s toolbox is the trick.