Ajax: Controlling the Scroll

By Deane Barker on August 25, 2005

This is going to seem obvious, but I hit on something today about Ajax. I knew this in the back of my head, but it jumped to the front today —

Ajax can do a lot, but the most simple and powerful thing it can do in certain, specific instances is elmimnate the page scroll.

Page scrolling may seem simple and innocent, but think about it – when you post a form or click a link, the entire page reloads into the browser at the very top. So if the user was low on the page doing something, the page is now scrolled all the way up so they have to do something very frustrating: re-orient themselves to the data they were just looking at. (And anchor tags don’t help. At best they’re hopelessly inaccurate in terms of re-locating where the user was.)

Consider this scenario I’m working on —

I’m creating a simple Web-based file-browsing system where the user can explore a file and folder structure via a little Web interface. This interface, however, is part of a larger screen of data – it’s just a little window towards the bottom of the page.

If – when the user clicks a link to enter a subfolder in the list of folders he’s looking at – the entire page reloads, then the user has to scroll down to find the interface again, re-orient themselves to the space they were looking at. Usability goes out the window with this method. Not just because they have to move the mouse or spin the wheel to scroll, but because they have to “re-figure out” where they were.

(Not to mention the audible “click” in IE when you click a link. I think that click really snaps people out of any contemplation they were in. It’s a signal to them that something has changed and reset, so forget what you were looking at before and re-adjust.)

But with Ajax, I could quietly just reload that little section of the page, so the user’s focus never strays from the interface within the larger window. This is huge for the user experience. Yes, there are other problems (where you are in this interface is not reflected in the URL, for one), but those pale in comparison to the benefits for these situations.

Again, Ajax is capable of a great many things. But if the only thing you do with it is use it to isolate “mini-interfaces” within larger interfaces, you’ll still come out way, way ahead in terms of usability.

Comments (7)

marcin says:

good point, Deane! but it’s another feature of AJAX that can be also (and easier) achieved with IFRAME

nevertheless, the AJAX method works quicker

Deane says:

it’s another feature of AJAX that can be also (and easier) achieved with IFRAME

Yes, that’s very true. There’s a fine line between when to use an IFRAME and when to use Ajax. I say use an IFRAME until you have a good reason to switch to Ajax.

Joe says:

Wouldn’t setting an anchor point with A name=”” and referring to it in the URL do pretty much the same thing? Or am I missing something?

Deane says:

Wouldn’t setting an anchor point with A name=”” and referring to it in the URL do pretty much the same thing?

In a very crude way. But the page will still reload, and the interface will “jump” some, and that will still throw people off.

And what if your “mini-interface” is big enough to scroll on the page – how do you know exactly where they were without hacking some Javascript-derived pixel count into the URL?

I am NOT saying we should eliminate page reloading altogether. But in some instances, this is – by far – th best way to go.

argatxa says:

IMHO the main advantage of AJAX is to be able to load stuff in a section of the page without having to reload (with a cost to the server) the hole page... the pages I work on are very very heavy.... and I try to avoid heavy hits as much as I can!!!

IFRAME? mmmm.... is it crossbrowser? And I prefer to hit the server asking for only the data that I need, formatting it on client with Javascript and passing the processing cost to the client....

Dion Almaer says:

There are very specific differences between iframe and XMLHttpRequest.

iframe’s are great if you want to tap into the browser history.

XHR is great if you do NOT want to do so.

Google Maps uses both. When you do a search it uses an iframe (which allows you to go back and forward between your searches without leaving Google Maps).

XHR is used to go back and get data needed for the map.

So, there are distinct use cases for various approaches, and you just need to work out which technology fits for your case.

Dion Almaer


MN says:

Hi Is there any code that automatically can go to the top of the main page when an iframe reloads?