The Semantics of "Reload"

When I click the Reload button in my browser, an HTTP request is issued that is substantitally the same as the one which created the page in the first place (well, not entirely in the case of POSTs). It strikes me that with AJAX applications that this functionality is somewhat outdated. With an AJAX application, I might want to just update part of the page.

For example, on StyleFeeder, if you’re looking at the homepage, you may just want to refresh the “Latest Added Items” data and the tag cloud. Reloading the entire page might be useful to some people, so I don’t think that we can totally dispense with the Reload button.

On the portal, I have a bunch of portlets from various news outlets, weather, and stock quotes. When I want to see updated content, I shouldn’t have to reload the entire page. I should have a button that does a “Refresh” of the content and pulls in updated news stories, quotes and weather forecasts in an AJAX style. I’m almost wondering if we need a “Refresh” button.

The UI of the web browser has remained substantially the same since I first started using Mosaic back in 1993:

  • Stop
  • Back
  • Reload
  • Forward
  • Address bar
  • Display area

Of these, it strikes me that the “Reload” button is the only one that is really starting to suffer based on new architectures. Of course, the Back button has been troublesome from the start, so we can’t ignore that.

However, I cannot imagine having to explain to users the difference between “Reload” and “Refresh”. It strikes me that having some kind of an API for the browser to hook into the “Reload” button on your browser toolbar to override the functionality to perform partial page refreshes might be useful, but that will open up a Pandora’s box in itself.

In any event, this is one of the first times in recent memory that I can think of a non-plugin technology that has caused an architectural crack to appear in the otherwise solid UI features of the modern web browser.

3 thoughts on “The Semantics of "Reload"”

  1. I fail to see how the reload button has become less useful because of AJAX. I would think its become more useful, as it is the easiest way to deal with faulty AJAX operations. There’s nothing stopping someone from putting a refresh button on the page themselves. If that behavior became common then reload would be seen as a safety/override switch just like the reset button on some computers.

  2. There’s nothing to stop you from putting a “Back” button on every page of the web either.

    Right now, we rely on hokey polling mechanisms for reloading data. I can imagine cases where having the ability to refresh data would be advantageous, such as auction sites like eBay. And modern browsers don’t have a way to take advantage of this.

    I’m not suggesting that we should get rid of the back button and your evidence of getting around faulty AJAX operations is a good example of why we should avoid doing this.

    If you view the browser strictly as a HTTP user agent, there’s no way that you would be convinced by the point I was making. If you view the browser as something that can or should interact with web applications, then maybe this starts to make a little more sense in those terms.

  3. “If you view the browser as something that can or should interact with web applications, then maybe this starts to make a little more sense in those terms. ”

    Good point. I think it’s easy to forget this might happen someday because attempts to have the browser actually undersatnd the content (e.g. Microsoft’s SmartTags and Google’s AutoLink) have largely been met with suspicion if not derision. The closest I think its come to interacting has been via frames (where you can, in fact, reload part of a page), and imperfect implementations have led that to be blacklisted by the UI community.

Comments are closed.