On Gawker and Hashbangs

Gawker recently finished a transition of all their websites to a new design, and some of the technical decisions they made have upset web standardistas, the most prominent missive being this one by Mike Isolani, a Yahoo employee (all quotes in this post come from his essay). The complaints center around Gawker’s reliance on JavaScript to render the page and their accompanying use of the “hashbang” (#!) in the URL. There are a lot of valid concerns with the hashbang design, and specifically with the way Gawker has implemented it, but the complaints all miss or ignore one key fact: there is no other way to get the behavior enabled by Gawker’s new design.

The Bottom Line

The only way to achieve what Gawker’s new design does, cross-browser, is the way they’ve done it. There are ways to improve the design for newer browsers, but the foundation would still be what Gawker has implemented.

And despite what some are claiming, the design does more than just “look cool”; it actually enables behavior that many find useful and can be achieved no other way.

So why use a hash-bang?

Out of all the reasons, the strongest one is “Because it’s cool”. I said strongest not strong.

It’s an insult to the tech community that an article with this claim gained so much traction. Any web developer that truly knows his stuff will tell you what a hashbang-based, JavaScript-based site enables. In the case of Gawker’s two-pane design, it allows the reader to not lose his place in the article list as he reads through multiple posts. It also increases the perceived speed of the site, because jumping to a different article doesn’t refresh the whole page.

Let me give an example of a real world benefit. If you are anything like me, you visit the front page of a Gawker site (for me, it would be Kotaku) and you scroll through the list of articles, opening any you want to read in a new tab. Why? Because I don’t want to lose my place in the article list by clicking into the story, and I don’t want to have to hit the back button once I’m done reading that particular article. So after a few minutes I’ve got 10 tabs open, which starts to bog down my browser and eventually my whole computer. With Gawker’s new design I can scroll through the list, click on each article as I go, confident that I won’t lose my place in the article list. My tab bar stays sane and my computer’s fans stay off.

The Details

But what are the complaints of the web standardistas? Even if Gawker’s finds success with their “non-standard” redesign, should others avoid going down a similar path? Let’s evaluate.

  • The site won’t work with JavaScript turned off.

Although it’s hard to find truly authoritative numbers, most reports indicate that over 98 percent of users have JavaScript enabled.

  • The site won’t work if the JavaScript fails to load, or if there is a syntax error (such as an extra comma) in the code.

This is the biggest red herring of the bunch. Guess what? ANY website won’t work if parts that it relies on fail. Relying on the JavaScript to load is no more dangerous than relying on HTML to load. In writing about this, Mike and others make it sound like building a website that depends on JavaScript is akin to rubbing your lucky rabbit foot and putting on a blindfold before starting to code.

Every URL references the LifeHacker homepage. If you are lucky enough to have the JavaScript running successfully, the homepage then triggers off several Ajax requests to render the page, hopefully with the desired content showing up at some point.

He’s purposefully making it sound far brittler than it really is. This is like saying that when you visit a traditional URL, “If you are lucky enough that the server is running successfully, the request triggers several function calls, hopefully with the desired content being returned at some point.” The reality is that all web services are dependent on their constituent parts working.

I think part of the reason for this perception of JavaScript as brittle is that for a long time JavaScript was an “extra”, and so was coded by people who were not overly familiar with the language and was then either tested poorly or not tested at all, resulting in broken implementations. This led to the perception that the language itself was the problem.

  • The URL looks ugly.

Here’s a Gawker URL under the new design:
And here is that same URL under the old design:
That’s all I have to say about that.

  • HTTP/1.1 and RFC-2396 compliant crawlers now cannot see anything but an empty homepage shell.

This is a business concern. How important is it for your business to show up in search results? More specifically, how important is it for your business to show up in search results besides Google1?

  • Caching is now broken.

Another business concern. If your infrastructure can handle the requests without caching, then there is no issue. If it can’t and you want to have a more JavaScript-based approach, modify your infrastructure to support it.

  • The potential use of Microformats (and upper-case Semantic Web tools) has now dropped substantially.

A real travesty.

  • Facebook Like widgets that use page identifiers now need extra work to allow articles to be liked.

So you’re saying they still work? So what’s the issue here?

  • Using cURL to retrieve one of the new Gawker URLs will not return the correct content.

Good thing I’ve got this here browser, then.

  • The new URLs “don’t map to actual content”.

So, requesting the URL assigned to a piece of content doesn’t result in the requestor receiving that content

Actually, each URL does map to content. It just requires JavaScript to complete the mapping.

The Switch to Web Apps

Despite my flippant responses, the last two points bear further discussion. What’s happening here is that the web is evolving. Many sites are migrating towards a “web app” model, where the site operates like a self-contained application rather than a network of interrelated links. Along with that the browser and all its functionality, including JavaScript, are elevating from a GUI wrapper around cURL commands to an element of the web stack itself.

This change is making some developers uncomfortable. In their effort to explain their discomfort they are coming up with all sorts of rationales for sticking with older methods of web site design. Although there will surely be some bumps along the way, the reality is JavaScript is going to find its place as a standard, accepted part of the web stack. Other methods of retrieving web content will either have to adjust (such as Google’s efforts to index JavaScript-loaded content) or be relegated to secondary or special-purpose status, such as cURL.

Business on the Web

One last point I want to make. Even if Gawker’s new design truly was a catastrophe on the code side it could still be the right decision for them, because ultimately they are a business and their infrastructure and code choices should all be made in support of their business goals.

I think Gawker understands that they have to serve their users. From the user’s perspective a lot of these questions don’t matter. Who cares if the server parses the URL or the client does? Who cares if the parsing is done client side, or if the browser has to retrieve the content based on a URL fragment that it stored? That’s all implementation.

As much as web standardistas wish it wasn’t so, all these technical decisions (in a smart organization) are ultimately business decisions. Who cares if the design doesn’t conform to the W3C2 URL standard? The real questions are: How is the end user affected? Does it deliver a superior experience? Does it work for the audience Gawker cares about? Does it increase engagement? And of course the only question that really matters – will the design lead to increased profits? I can easily imagine that Gawker did an analysis and came away with the conclusion that this change would deliver where it really mattered.

1. The “bang” part of the hashbang design is not technically necessary, but Google devised using an exclamation point after the pound symbol as a signal to its indexer. Using the hashbang allows Google to index the content despite it being loaded dynamically via JavaScript. More here.
2. The World Wide Web Consortium, responsible for the standards on which the web is built.


Twitter Conversations Follow-Up

In a previous post I argued that Twitter clients should provide an easy way to see all the @ responses to a tweet, not just the ones that directly replied. I’ve since discovered at least one Twitter client that does what I want, and have realized that many Twitter clients do what it sounded like I wanted.

I wrote:

Twitter clients should add a tab on a user’s profile page for viewing tweets directed @ that person.

Well, most Twitter clients do that, including the official Twitter client. But that’s not exactly what I’m looking for. What I really want is way to quickly get to all the @ replies from the tweet itself without having to click through to a profile page and then a tab within the profile page.

At least one application does this. Twitteriffic has a “Replies to this author” action available from the detail view of any tweet.

Part of the reason I wasn’t aware of this is because I got rid of Twitteriffic on my iPhone after a while. I just couldn’t handle its confusing interface. Turns out that the guys at The Iconfactory realized they may have overengineered the app and dramatically overhauled the interface with version 3, released in June of last year. They really did a fantastic job of keeping a lot of functionality while streamlining the interface. It’s now my default Twitter app.

Putting the Phone Call in its Place

The iPhone, as is evident from its name, started life as a phone.

Despite Steve Jobs clever reveal of the iPhone as three separate but equal products in one package (an iPod, an “internet communication device”, and a phone), most consumers saw it as an evolution of the mobile phone. It was a phone, plus a bunch of other stuff.

But the iPhone is no longer a phone, it’s a mobile computer (a post-PC device, Jobs would say), and iOS needs to change to reflect that.

Phone calls are still given primacy in the OS. If I’m in an app and a call comes in, my entire screen is taken over by the incoming call UI. I have to either decline the call or wait for the call to end1 to get back to what I was doing. If I choose to accept the call I’ll be dropped into the phone app when the call ends, not into the app I was using when the call came in. This was especially irritating before iOS 4 and multitasking. Similarly, if I’m in an app and I click on a phone number that initiates a phone call, I’m taken out of the app and into the phone app for the call.

Text messages are slightly better but not by much, the key difference being that an incoming text message does not take over the whole screen, instead displaying a notification. Otherwise text messages exhibit the same behavior as phone calls: answering and initiating a text message takes you out of your current app and into the messaging app.

Contrast these with the email interface of iOS. If I’m in an app and an email comes in my phone buzzes; that’s it. Besides the vibration and audio chime, I’m not interrupted in any way. If I’m in an app and I click on an email address to send an email, an email “sheet” slides up where I can type my email. Clicking “Send” sends the message and dismisses the email interface, leaving me exactly where I was before I clicked the email link.

The email interface of iOS used to work differently. Prior to iOS 3, clicking an email link in an app would switch you to the email app to compose and send your message. But Apple realized that this was not optimal (especially before multitasking) and so devised the email “sheet” method.

Apple should switch the phone and messaging interfaces to work like email.

Better yet, all three should be unified into a standard communication framework that third-party applications can also link into. If I’m going to get pie-in-the-sky here (if I’m not there already), this new framework would hook into a new notification system.

My dream is that I have the same options for each method of communication: I can choose whether I get a notification that interrupts to some degree (the current pop-up message or some future implementation), that alerts but does not interrupt (vibration or audio cue), or that neither interrupts nor alerts. And responding or initiating each method of communication would use the “sheet” method, allowing me to stay within any app I may be in.

Some may argue that the differences between the OS’s handling of phone calls, text messages, and email reflect an inherent difference in the nature of each type of communication. I disagree. Today an email may be more important than a phone call or a text message. For some people a Skype message or AOL IM could be more important than any of the natively supported methods of communication.

Apple loves to be the first company to drop old technology and old ways. Treating phone calls like they are more important than other communication methods is the old way.

1. Waiting being my preferred choice as declining a call sends the caller directly to voicemail, tipping them off that I chose not to answer.