I am working on an existing website that we're adding some additional functionality to. A large number of users visit the site in the following manner:
Page A -> Page B -> Page C -> back button to page B -> Page D -> back button to page B, scrolling -> Page C -> back button to page B, scrolling -> Page E, etc, etc.
There is an alternative use case of Page A -> Page B -> Page C -> Page D -> Page C -> Page D -> Page E ..., but that is a non standard UI element (links on the page) and we want to support the back button as well as this path.
Basically, the flow is from a search results page to a details page, and back to the results page, and to another details page, etc, etc.
Currently, these pages are all normal html pages, crawlable. We need to maintain that--so we can't move everything into a AJAXified web application.
However, the javascript download and especially parse times take a significant amount of time and lock up some browsers.
We'd like to load the page C and further pages (including later repititions of page B) via XMLHttpRequest to eliminate this load/parse time. We have that working--we attach a javascript listener to the urls a user will click on to get to page C/D/E, and can load those pages via javascript.
However, the issue is that when you scroll down page D, and then hit the back button, browsers remember scroll values. That is, if you scrolled 50 pixels down on page B, then you go to page C, then you scroll 300 pixels down, and then you hit back, you are immediately scrolled to a position 50 pixels down, then the page B content is loaded. This creates an extremely unpleasant jump for the users.
Options we've explored or thought about:
- freezing the scroll bars (document.style.overflow = hidden)
- trying to cover the screen with a loading overlay whenever the back button is pushed
- remember where page B was, and then when the back button is hit, scroll up to that slowly.
- loading page B via XHR the first time. There are a lot of paths into A, but this might be worth doing if there is no other alternative, because there is no issue with position jumping in the alternative use case, where every page is loaded via XMLHttpRequest.
- loading page B when you first visit page C, in hopes that when the back button is pressed, the page B content will load so quickly as to be transparent. This was not the case.
- have page B, on first render, load itself through XHR. Extra work for the browser and server, but might be promising.
- add a loading overlay to every page, and then have javascript remove it. This seems like a poor choice, because then the site is unusable for browsers without JS turned on.
- have the javascript add an overlay to page B just before the user is sent to page C, and see that it remains somehow so when the back button is pushed, the overlay is already present. Not sure if this is possible.
The first three solutions both require that the javascript know when the back button is pushed. As far as I can tell, there is no way to do this in javascript (you can tell when the content after the hash in the url has changed, but not how or why. See http://stackoverflow.com/questions/2122290/how-to-distinguish-browser-back-forward-button for more.
Gmail seems to have solved this by having the search results page (page B in the flow above) be loaded via XHR (because page A is a small loading gif), but that isn't acceptable in our case (because page B needs to be crawlable).
If it helps, I'm using GWT to write all this javascript, but would be more than willing to write some native js code if need be.
Does anyone know any websites or frameworks that have solved this problem? Or does anyone have any other ideas?
Thanks, Dan