If you look at my profile page on Huffduffer, this is what you’ll see:

my details,
what I’ve huffduffed,
links to subscribe to my podcast and
my tag cloud.

That’s the core information for that page, preceded by a header with site navigation and followed by a footer with some additional links.

Because I’ve provided a URL with my details, there’s some extra information displayed in the sidebar:

my other profiles on the web, as determined by Google’s Social Graph API,
MP3s recommended by Last.fm,
my latest updates on Twitter.

It’s a similar situation if you look at a piece of audio I’ve huffduffed. The core information is:

all the details about the audio (title, description, tags),
who else has huffduffed this,
possibly-related items and
links to share and embed the audio.

In addition, because I’ve used a machine tag—book:author=cory doctorow—the sidebar contains:

related articles from The Guardian,
sales information from The New York Times,
books on Amazon.

In both cases, this supporting information isn’t essential; it’s just nice to have.

There’s a potential performance problem though. Because this extra information is coming from third-party services—and despite the fact that I’m doing some caching—it could delay the display of the whole page. So I took some time on the weekend to adjust the architecture a little bit. Now the extra information is requested with Ajax once the core information has already loaded. This is lazy loading.

Now I’ve introduced a dependency on JavaScript, which is far from ideal, but because this is just “nice to have” information, I think it’s okay if it isn’t seen by a subset of visitors.

In fact, because this extra lazy-loaded stuff takes up valuable screen real estate, I think it might be acceptable to only serve it up to visitors who have the screen real estate to accommodate it:

if ($(document).width() > 640) {
// do lazy loading here
}

So if you load my profile on a small screen, you won’t see my latest tweets or my Last.fm recommendations. Likewise if you look at something I’ve huffduffed that’s tagged with music:artist=radiohead you won’t see information from Last.fm, pictures from Flickr or albums on Amazon unless you load the page with a wide enough viewport.

Now it could be that the real issue here isn’t viewport size, but connection speed …in which case I’m making the classic error of conflating small screen size with limited bandwidth. A script like Boomerang, which attempts to measure a user’s connection speed, could be very handy in this situation.

Lazy loading is the new fold

I was chatting with James about the implications that lazy loading could have for earlier phases of the design process: wireframing, page description diagrams, and so on.

Traditionally, you’ve got only two choices when judging what content to include: either something is on the page or it isn’t. You can use hierarchy, position and contrast to emphasise or de-emphasise the content but fundamentally, it’s a binary choice. But with conditional lazy-loading there’s a third option: include some content if the user’s circumstances warrant it.

Once again, Luke’s Mobile First approach is a useful thought experiment. It can help prioritise which elements are core content and which could be lazy-loaded:

Mobile devices require software development teams to focus on only the most important data and actions in an application. There simply isn’t room in a 320 by 480 pixel screen for extraneous, unnecessary elements. You have to prioritize.


So when a team designs mobile first, the end result is an experience focused on the key tasks users want to accomplish without the extraneous detours and general interface debris that litter today’s desktop-accessed Web sites. That’s good user experience and good for business.

Sometimes there are political reasons for wanting the “extraneous detours and general interface debris.” Lazy loading for large-screen users could be the least worst option in that situation. Semantically speaking, the kind of content that might be marked up in an aside element might be a good candidate for lazy loading …if the viewport is large enough.

I have a feeling that we’re going to be seeing a lot more of lazy loading as the responsive web design revolution rolls on. Used judiciously, it could provide plenty of performance benefits. But if it’s taken too far, lazy-loading could be disastrous, resulting in sites that rely on JavaScript to load their core content—I’m looking at you, Twitter.

Tagged with
responsive
design
lazyloading
javascript
ajax
huffduffer
mobile

I wrote a little while back about my feelings on hash-bang URLs:

I feel so disappointed and sad when I see previously-robust URLs swapped out for the fragile #! fragment identifiers. I find it hard to articulate my sadness…

Fortunately, Mike Davies is more articulate than I. He’s written a detailed account of breaking the web with hash-bangs.

It would appear that hash-bang usage is on the rise, despite the fact that it was never intended as a long-term solution. Instead, the pattern (or anti-pattern) was intended as a last resort for crawling Ajax-obfuscated content:

So the #! URL syntax was especially geared for sites that got the fundamental web development best practices horribly wrong, and gave them a lifeline to getting their content seen by Googlebot.

Mike goes into detail on the Gawker outage that was a direct result of its “sites” being little more than single pages that require JavaScript to access anything.

I’m always surprised when I come across as site that deliberately chooses to make its content harder to access.

Though it may not seem like it at times, we’re actually in a pretty great position when it comes to front-end development on the web. As long as we use progressive enhancement, the front-end stack of HTML, CSS, and JavaScript is remarkably resilient. Remove JavaScript and some behavioural enhancements will no longer function, but everything will still be addressable and accessible. Remove CSS and your lovely visual design will evaporate, but your content will still be addressable and accessible. There aren’t many other platforms that can offer such a robust level of loose coupling.

This is no accident. The web stack is rooted in Postel’s law. If you serve an HTML document to a browser, and that document contains some tags or attributes that the browser doesn’t understand, the browser will simply ignore them and render the document as best it can. If you supply a style sheet that contains a selector or rule that the browser doesn’t recognise, it will simply pass it over and continue rendering.

In fact, the most brittle part of the stack is JavaScript. While it’s far looser and more forgiving than many other programming languages, it’s still a programming language and that means that a simple typo could potentially cause an entire script to fail in a browser.

That’s why I’m so surprised that any front-end engineer would knowingly choose to swap out a solid declarative foundation like HTML for a more brittle scripting language. Or, as Simon put it:

Gizmodo launches redesign, is no longer a website (try visiting with JS disabled): http://gizmodo.com/

Read Mike’s article, re-read this article on URL design and listen to what John Resig has to say in this interview .

Tagged with
urls
javascript
web
development
ajax
google
rest
twitter
gawker
lifehacker
robustness
accessiblity