Information Management Weblog

Ajax, InnerHTML, and the back button

I've been playing around with a little quick-n-dirty "meta" search system. In short, the script takes the term entered by the user, queries a couple of third-party search engines, then parses (read: screen scrapes) and displays the results to the end-user. Because the biggest issue here is the time it takes for the third-party servers to process the query and respond, I figured I'd use a bit of that Ajax magic that has been going around. So, now the script updates the page (without reloading) as soon as each of the server responds, meaning the user can see results right away, even as the script still chugs away on the slow parts. This works quite well.

I'm using the prototype.js system that is included with Ruby on Rails. The javascript library doesn't depend on Rails, and in this case I'm using it with a combination of PHP and Python scripts. Basically, the script makes a call to the server and then places the HTML it gets in response inside a div. The javascript that makes this all happen is called using onload(), but I've also toyed with just plopping it in the code, with little difference in functionality.

So, everything works like a charm, and the user is eventually presented with results from multiple sites. Then, Mr. or Ms. User clicks on one of the results, and leaves the site. So far, so good. But, trouble arises when the user clicks the back button and ends up back on the search page. Firefox re-fires the onload(), and the results appear quickly (I'm caching the results on the server side). IE6 doesn't re-fire the onload(), leaving me without results. This isn't good, seeing as a healthy (but declining) portion of our users are using IE.

After a little sleuthing, I came across this page. Taking advantage of the fact that IE's history/cache store pages with distinct URLs (I believe), these guys show a method using the Dojo toolkit to modify the URL by appending a "#" with a string of numbers to the URL. Voila! This should do the trick, but I haven't tried it yet.

I do have a couple of little concerns. One, it does muddy up the URL a bit. I can live with this, though. But, of more concern is the fact that it would create two entries in the history/cache for the same page. One would be blank, the other would have the results in it. Users would then have to step back through the blank page. And having watched many a user rely solely on the back button during usability tests, I'm not wild about this.

So, I see a few potential solutions:

• Find a different Ajax toolkit. Someone may have solved this?


• Maybe there is some javascript do-hickey out there that would cause the IE to re-fire the onload() event, making it's behavior match that of Firefox.


• Try to disable client-side caching so the page has to reload. Not sure if there is a clean way to do this, other than to turn my form from a get to a post. That would, of course, bring up an annoying dialog box, I think.


• Don't use Ajax at all, and have the whole thing happen on the server-side and send everything all happy-like to the browser. This is fine, except for the speed issues. That is, it's slow. Of course, I could slap some sort of interstitial in there, like an airline reservation system.