The Hash-Bang Conversation.
Mike Davies kicked off a discussion around the Gawker and Twitter URL pattern. I can’t reproduce a tenth of what has been said around the Internet here, but I’d like to add a few thoughts on behalf of good design. Let’s start by establishing the relevant arguments:
Mike Davies, Breaking the Web with Hash-Bangs:
Gawker, like Twitter before it, built their new site to be totally dependent on JavaScript, even down to the page URLs. The JavaScript failed to load, so no content appeared, and every URL on the page was broken. In terms of site brittleness, Gawker’s new implementation got turned up to 11.
A follow-up from Tim Bray, Broken Links:
There is no piece of dynamic AJAXy magic that requires beating the Web to a bloody pulp with a sharp-edged hashbang. Please stop doing it.
Jeremy Keith in Going Postel:
I’m always surprised when I come across a site that deliberately chooses to make its content harder to access.
What are we really talking about here?
Each of these articles, from people more brilliant than I, none of whom I have ever had the chance to meet or speak with, presumes you understand one critical fact: his individual cause is not the only thing you need to worry about.
The ostensible focus of the discussion is the brittleness of hash-bang style URLs. In fact, Jeremy Keith is having a conversation about accessibility. Tim Bray focuses on robustness, flexibility, and the curious indifference to basic computer science principles. Mike Davies touches on many points with concerns regarding JavaScript dependence, exclusive site crawling, broken analytics, and more. Ben Ward partially defends JavaScript-based URLs on the grounds of increased performance, though he also acknowledges at least temporary problems as browsers embrace a new paradigm.
Web development is an intricate puzzle.
The anti-hash-bangers, as we’ll call them, are fighting a hopeless rearguard action here, and they know it. They are a much needed force for conservatism, a constant reminder of not only the way things used to be but why they used to be that way. Thoughtful conversation regarding—and intense advocacy for—strong engineering and pervasive accessibility is undeniably good. Nobody wants information to be hidden or compelling experiences to be walled off by immature decisions.
This, however, is a woefully incomplete picture of the Internet, which has now extended its tentacles into nearly every device imaginable and will continue to do so. Web pages are merely a small part, a part which until just recently looked and performed about as unsatisfactorily as theoretically possible. Complete page refreshes, limited control of layout, abrupt—literally instantaneous—transitions between state, a set of utilitarian typefaces, and a browser landscape so bereft of consistency as to discourage even the strong-hearted.
Fortunately, we are rapidly moving out of that phase into a place where websites built with the common tools of the browser can look and feel as delightful as native applications. This is a wonderful achievement. Loading only tiny bits of information as necessary; choosing typefaces appropriate to the tone of the site while maintaining accessibility; rounding corners, dropping shadows, and fading elements all via native, hardware-accelerated browser features rather than with clever hacks and verbose JavaScript techniques is the irresistible tide of the future.
We must, therefore, always balance the desire to delight visitors in thousands of large and small ways with the tactical needs of reliability, accessibility, and speed. I know Mike Davies, Tim Bray, Jeremy Keith, Ben Ward and all the other hard-working, smart web designers and developers understand this fact implicitly. Their tireless efforts to speak for the traditional strengths of the Internet are inspiring. I merely note that empathy for the user means good visual and interactive design not just a web page that always loads correctly and in the last place you looked for it. ((Please don’t foist a false dilemma of either good engineering or good design onto this conversation. There will inevitably be growing pains and temporary setbacks, but everyone should agree the ultimate goal is both good engineering and good design.))
