The March 2012 layout of Bits Pushed Around extends the experiment I have been carrying out for a little while now: building a project that sticks as much as possible to the Low Requests Footprint Manifesto, whose main idea is for a user not to download the same bits twice during a given navigational experience.

Incremental vs. All-At-Once

With the February 2012 version of this website, I decided to go for a rather head-on approach where the whole of the website would be downloaded at once. One of the problems that arose with that approach is that, even though it made sure that nothing would be downloaded twice, a decent amount of data not pertaining to the user would have to be downloaded, which I didn’t want.

So how could the whole of a website be consumed without downloading the same bits twice and without downloading content that the user hasn’t chosen to download?

The idea of incrementing the HTML document while the user browses my blog came as an obvious solution to that issue, but February was drawing to an end and I was lacking the time to implement it. I must also admit that I wanted this All-At-Once pattern documented somewhere, as it can be seen as the starting point of any project adhering to the Low Requests Philosophy.

So, March 2012 has been about building a layout around the Incremental Navigational Pattern.

What Lies Behind The Word “Incremental”

While that name may suggest some new, super-hype concept, there really isn’t anything revolutionary behind it. All it does is re-appropriate the well-known pattern of tab navigation: all the internal links of Bits Pushed Around could be seen as tabs and the [role=main] div could be seen as the tab content. Every time a link is clicked, an xhr request is performed, which returns some bits of HTML that are appended to the [role=main] div. A little javascript object keeps track of the pages requested during a given navigational session and if a page is requested more than once, its visibility is toggled instead of sending the xhr request again.

Browse this layout while inspecting its DOM: all should quickly become clear.

A Few Vague Notes On Some Caveats I’ve Had To Face

Building that navigation system was so particular that I can’t really turn this article into a tutorial or a tips-and-tricks session. So please excuse the vague ambiguous nature of this post. What I can do, however, is mention a few caveats you may encounter should you ever decide to build a similar navigation for your website, notably with xhr requests.

AJAX (even though it doesn’t really make sense to use that acronym here since, after all, the requests made in here are actually synchronous) has had some bad press in recent years -and rightfully so- because it led to issues similar to those affecting iFrames: browsers’ broken back button, urls laughing at the REST-ful nature of the HTTP protocol, and, last but not least, accessibility issues (screen readers not being told when and where updates occur).

Here are some of the checks I’ve done to ensure that the March 2012 layout of Bits Pushed Around would be as user-friendly as can be.

• If javascript is disabled, this website should work properly. This is a very, very basic check but unfortunately, as the mighty Jenn Lukas showed during her speech at the JS conf 2010, there are still many websites which just don’t care about users browsing their pages without javascript.
• The urls of this website should be accurate and respect the REST-ful nature of the http protocol. Browsers have implemented ways to make xhr requests a lot friendlier than they used to be. The history API and the onpopstate event solve both the issues of the back button and the REST-ful urls (if that actually makes sense...). There are some discrepancies to handle when it comes to the onpopstate event, though, as it is not fired in a consistent way across browsers. Nor is there a native way of knowing if a user hit the “back” or “forward” button, which is something you will have to implement if you need it (in my case, I worked around this issue by analyzing the url of the past articles pagination every time the event was triggered).
• The search results shall not be paginated. Pagination is something that I find quite annoying, for reasons that Jeff Atwood sums up better than I could ever do in this article. Even though this website doesn’t have thousands of articles to return, I still decided to avoid pagination, if only for the pleasure of writing about my distaste for it and making a point. But what about past articles? Aren’t they paginated? Yes, they are. And they are for the following reason: experimentation. Paginating past articles was a way of performing some pushState stunts; I’ll admit it.
• This website should be easy to navigate for screen-readers. As far as accessibility issues are concerned, ARIA does a nice job of telling browsers that that an area is a live region, that is, a region likely to be updated via the use of xhr requests. I decided to set [role=main]@aria-live to “assertive”, as this is the value that best mimics a new page load in a good old “Per-Page” navigational pattern. I would have liked to take control of the tab key to help people navigate from one page to the next (as if the main content were some sort of carousel) but I didn’t find the time to implement it. It’s certainly a feature that will appear in a future layout.

What About Lowering Your Requests Footprint If You Perform Xhr Requests?

It may seem quite inconsistent for me to advertise for xhr requests, especially considering that line of the Low Requests Footprint Manifesto:

I will even try to tend toward a total number of GET requests of one.

I must admit that there is a flaw in the manifesto there. Maybe not a flaw, but a very, very hard thing to achieve. It’s more of an idealistic statement than anything else. To this day, I can’t think of a way to have the client request the server only one time and get the exact content the user wants without having to alter the document in any way by performing any subsequent request. I guess those “behind-the-scenes requests” fall into a grey area where they must be tolerated as long as they don’t lead to the downloading of bits in excess.

The Fun Does Not End Here

This layout was also a good opportunity to put into practice some of the ideas Mathias Bynens has come up with in his article named “Displaying hidden elements like <head> using CSS”. Even though Mathias is mainly interested in the experimental side of things, reading his article convinced me to take the plunge and go for a practical use of displaying the <title> tag.

Indeed, since HTML headers aim at creating a meaningful document outline, the idea of a site name displayed in the <h1> tag is quite nonsensical (when you think about it, the title of a book, for example, isn’t its first chapter, neither is it ever considered as a super section containing smaller chunks of sections). Yet, having the site name displayed in some anonymous <p> tag never seemed satisfying to me either, the name of a site obviously deserving some kind of emphasis mark-up-wise.

Displaying the <title> tag is a perfect solution to solve those problems as a) an existing element is used instead of adding a new one (that’s a few bits saved) and b) this specific aspect of the content reveals its importance -its role- by relying on the emphasis inherent to the <title> tag, which makes this specific aspect of the content both semantic and meaningful, which is always a nice little victory in our day and age.

And Some Phony-ness To Conclude

In conclusion, I’d like to take a moment to publicly slap myself in the face in a typical display of self-loathing (that will hopefully becoming the trademark tone of this blog), and point out some problematic aspects of the code powering this layout.

When a user performs a search, some articles may actually be downloaded more than once (even though they are not injected into the document again). I didn’t have the time to code something on the server side that would help bypass --and not return-- articles already present in the HTML.

My js code is not refactored. It is filled with what I consider inconsistencies of all kinds. I wish I had time to improve it, but redesigning this website every month is also about being über-pragmatic. And making mistakes. I have been a bit lax in planning my application. I did not take the time to abstract some portions of my code to make it re-usable in various contexts. It immediately bites back.

The same could be said of my stylesheets.

The same could be said of my mark-up.

Well, there is no argument here: burning yourself at the stake of nerdiness for mistakes that maybe less than 0.01% of the world population can fully appreciate is quite cathartic.