A while back I discussed JavaScript-rich web applications, with the entire client side working completely out of the browser.  Applications like Remember The Milk utilize this type of user interface to create a better experience, which is in my opinion the way web applications really should be like.

One of the issues that troubled me back then was how to overcome JavaScript single-page navigation while having to cope with traditional browser navigation.  After looking into it, I found what I was looking for; but first, I’ll elaborate on the subject:

All-in-one-page web applications

It’s really cool having a web application that does not require a refresh each time you touch something.  Most websites work in the old fashioned way – you click a link and navigate to another page.  What really happens is your action sends a request to the server to fetch another page, sometimes with specific parameters passed to it.  The server then creates that page for you, send it back, and the browser displays it.  What you as a user see  after clicking the link is a blank page, you wait for the page to load, and then you can move forward.  Even though this type of behavior is common among websites, it could be very uncomfortable for the user.  Come to think of it – none of us are used to this type of behavior with our desktop apps, are we?

Some web applications, like the Google app suite, Remember The Milk, and others utilize a different technique: when you click a link, like navigating to the Sent mailbox on Gmail, the page does not disappear and then reloads again.  What you do see is a “Loading” message at the top, and then the new mailbox just appears at its right place.  This type of user experience is what we should all hope for in heavy-duty web applications.

How does it work?

Anyone who knows JavaScript can figure out a way of doing this, but here’s the basic plot:

The page that you initially get from the server actually contains more than one page – it contains several, while only the one that is currently in focus is shown, while the other ones are hidden.  When clicking a link that should lead you to a new page, like the Sent Items box on your Gmail, the browser simply hides the current page (say, your inbox), and shows the sent items page instead.  This is done instantly, so you get the feeling that there were no reloads.

Furthermore, when the sent items page is displayed, it fetches all of the sent items data from the server, and simply dumps them into the empty page it already has.  This way, you enjoy the best of both worlds – you get a smooth user experience, while the actual data is always updated (since it reached you directly from the server in real time).

So what’s the problem?

The problem, as in many subjects, lies in history.  We are so used to this “page-mode” way of using websites and webapps, that we’ve learned some pretty nasty habits.  One of those is using Back and Forward buttons for navigation.

In a world where all of the websites use full page loads, back and forward makes sense.  When you navigate to a new page, the browser remembers the location of the previous one and will do what it’s supposed to do when the Back button is pressed – go back to the previous page.  However, when new applications are utilizing the “all-in-one-page” approach – then we have a problem: the back and forward buttons become useless.

Imagine this: I’m using a simple all-in-one-page web application to manage my emails.  I have an inbox and sent items box.  I navigate back and forth between them using my on-screen menu links.  What happens under the hood is simple – I never actually leave the page I got in the first place.  All the browser does is hide and show different parts of it, while fetching data from the server and updating it to the respective page section.

Oh no – I clicked the Back button!  I was in my sent items page, and hoped to get back to the inbox (where I was before) but no!  I’m out of the app altogether!

The browser’s history, that should contain all of my navigation track record, never actually recorded my inner-page navigation, since I never really left the page…  This is why classical browser navigation can sometimes cause huge usability problems when using an all-in-one-page web application.

Using anchors

Many apps have found a clever way to resolve this, by using anchors.  You remember anchors – these inner-page links that are used in tables-of-content, like in Wikipedia or a FAQ page.  These links that, once you click them, send you down to different location on the same page.  Well – instead of doing that, anchors might just be the way to solve all of our problems.

If we utilize anchors as part of our app’s navigation, we get exactly what we need: we change the browser’s location, which in turn records that location into its history, without actually leaving the same page…  This allows us to do what we always did – use the Back and Forward buttons, while still remaining in the same page!

Under the hood

After researching it a bit, a few ideas came into light.  The major issue that one should face here is the fact that browsers do not really notify you when you click the back-forward buttons.  You can use the “unload” event, but that doesn’t really cut it – you want to know where you are, not where you’re leaving.

So, basically, the way that this can be accomplished, at least according to what I’ve seen, is by creating a polling mechanism – something that periodically checks the current anchor that you’re in.  All you need to do is set up some sort of a timed interval, check the anchor, and act accordingly.

What you need to do is extremely simple:

All of the links that are used to navigate inside the same page should be anchored, like this:

<a href="#inbox">Inbox</a>
<a href="#sent">Sent items</a>

Then, there should be a JavaScript checker – something that periodically checks to see where the current page anchor is at, and then call a function that shows the page section shat should be shown:

window.onload = function()
{
     setInterval("check_anchor()", 100);
}
 
var current_anchor = null;
 
function check_anchor()
{
     if (current_anchor != document.location.hash)
     {
          current_anchor = document.location.hash;
 
          if (current_anchor == "#inbox")
          {
               // Show your inbox section.
          }
 
          else if (current_anchor == "#sent")
          {
               // Show your sent items section.
          }
     }
}

And that’s all there is to it.  The interval calls a function that checks the anchor, and according to that anchor’s value it directs it to the relevant piece of code.

This is obviously very basic; it does not take care of additional parameter (like “#inbox&q=33526″) and so forth – but you get the general idea.

Really Simple History

One of the better solutions that I’ve found out there is an elegant, lightweight, and free JavaScript library called Really Simple History.  You can add it to your code, initialize it, and direct the history event to a callback function of your choosing.

It really is a magnificent library – try it out!

This, for me, closes the loop for this issue.  Hope this helps – I’m going to use it!