UIEtips: To Refresh, or Not to Refresh

Jared Spool

October 8th, 2010

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&mdash 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 a 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 today’s UIEtips, I revisit an article from September 2008 on 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? I think you’ll enjoy it.

Read the article: To Refresh, or Not to Refresh

Eliminating page refresh is often done with Ajax and JavaScript—two subjects that our next UIE Virtual Seminar expert, Derek Featherstone, knows all about. Derek will help you navigate the minefield and maximize the effectiveness of using Ajax in your design. Get more details on his Derek Featherstone’s virtual seminar.

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.

Add a Comment