UIEtips: To Refresh, or Not to Refresh

Jared Spool

September 8th, 2008

I’ve often said good design is like the air conditioning in the room. If it’s working well, maintaining the right climate, nobody even notices it. You only pay attention to it when it’s not working.

Little design details are the same. If they are implemented well, the users won’t pay them any heed. If they are implemented poorly — causing delays and confusion — then the users will complain.

The big difference is that when there’s a problem with the little details, most users don’t know how to express what’s happening. It’s unlikely they’ll ask for piece of code or even for the interaction to match some clever web 2.0 site, even though that’s the right solution. They’ll just know something is not quite right and it will reduce the quality of their experience.

One of those little details is when to refresh the page. Years ago, there was no design choice here. The user pressed a button and the page redrew itself. Today’s technology, however, can change that, with Ajax and javascript giving us the power to modify a portion of the page, keeping the rest of the user’s frame intact.

In this week’s article of UIEtips, I talk about how to decide when page refresh is the right thing to do. How do you know when you should put in the extra effort and cost to eliminate it, and when should you put your resources into something else?

Read the article – To Refresh, or Not to Refresh

Eliminating page refresh is often done with Ajax and Javascript –two subjects that our UI13 expert, Jeremy Keith, knows all about. And knowing when it can enhance the design is an interaction design
decision — Interaction Design is what another UI13 expert, Kim Goodwin, is especially good at. Visit the UI13 conference site to learn about their full-day, in-depth seminars.

Have you come up with a strategy to eliminate page refreshes in your design? Did you decide that page refreshes were the better way to go for your users? We’d love to hear your experiences below.

3 Responses to “UIEtips: To Refresh, or Not to Refresh”

  1. Tony Blighe Says:

    Ajax is wonderful and page refreshes are a pain. That’s my view. We launched a fully Ajax driven content management system back in 2002. The whole of the user’s website is loaded into the browser at login, which can take a while, but once loaded the user can navigate from page to page and edit text, reorder pages, resize images and do everything else they need to do without any page refreshes at all. Users love it.

    It’s (much) harder to write and maintain the software but the benefits in terms of the user experience are very clear indeed.

    A side benefit is that Ajax reduces server load and bandwidth, as the server does not have to needlessly recreate the entire page, it just pops out the bit you need.

  2. Hendry Betts Says:

    Having been in Web Application Development since the early days of the dot com revolution through the web 2.0 evolution, I have seen a lot of different approaches to user interaction, and I have become a huge fan of the use XHR/AJAX. Primarily because, as Tony Blighe pointed out, the architecture of the applications that use AJAX for data interaction makes the server able to handle more transactions than a traditional refresh model would (less data up and down the wire). Plus the use of AJAX puts, what I believe as, the appropriate burden at the appropriate tier (the browser is responsible for rendering the view as opposed to the application server).

    There are ways to mitigate the “refresh” feel without having to round-trip the entire page from the server, such as the use of a “Processing Request” div that appears when an AJAX request is processed and hidden when the AJAX request responds. Using that methodology, even a quick response (sub-second)can be delayed using a simple ‘sleep loop’ that would allow the customer to actually see the div display prior to its being hidden.

    Because I have been involved in web application development from every level (server to browser) I am painfully aware of the impact of data transfers on the robustness, scalability, and rollout scale required for a given application. And I can say, unequivocally, that the use of AJAX/XHR has allowed my team to roll out high-usage applications on smaller server footprints than ever before. And even if I do have a large, beefy server, I can make better use of processor, memory, and IO through the use of AJAX than I ever could using tradtional Java, PHP or even PERL/CGI.

    As a caveat, I use AJAX for data only, not for fanciful UI. I still have a robust toolbox that contains all the ECMAScript tools I would ever need for dynamic HTML User Interaction.

  3. michelangelo Says:

    I am surprised to find no mention of accessibility concerns in your discussion of Ajax either here or in the article (except for what is implied in progressive enhancement).

Add a Comment