The Web Paradigm Four Years Later: King Browser
In my first post in this series, we took a quick look at where we were at the start of 2006 in re-defining the Web, and then asked, “How are we doing? Have we made progress during the intervening fourteen-hundred days?” The answer is, “Yes, we’ve made a lot of progress on the web, but we have yet to take the big leap. And we are in danger of taking some serious steps backwards.”
(Too Bad) The Browser Is Still King
When you think of the applications with the most impact on people’s day-to-day lives, chances are many of them will start with the letter ‘G’. Google has done an amazing job pushing the limits of what applications in a browser can do. They have pioneered new frontiers in web standards, compatibility, scripting, and browser user-interface capabilities. All of this has taken place inside of a web browser which is essentially unchanged since its inception. The browser is still king of the Web.
And yet, for all the advances in web user interfaces, they still suck. Take Google Calendar, for example: The CSS-styled interface is flat and ugly. Your options for different views are severely limited. Right-clicking brings up a context menu devoid of any calendar-specific context. Printing is a crapshoot, at best. When you have a meeting in five minutes, Google Calendar can’t interface with your desktop to provide a nice notification (like Growl or the Balloons); instead you get a ugly JavaScript pop-up and the default system sound. (And that’s not to mention more complicated issues like process isolation and window sizes and task switching!)
Need I go on?
Where Does Value on the Web Come From?
So why bother to use a web application like Google Calendar at all? It’s certainly not because we like the poor interface or lackluster usability. Rather, we get value comes from the accessibility of the important information it contains. Who gives a damn about a fancy calendar interface if it forgets your wife’s birthday! What’s more, we want access to our data. We want it to be available and accessible when we need it, in a format most appropriate for the access mechanism. Whether we’re scheduling our next hair cut on the iPhone, planning a trip home on our PC, or booking a meeting room at work, it has to be accessible any place and any time. A calendar in the cloud does that.
And it is easily shared with people you know and other systems you use. Metcalfe’s Law predicts that the value of our individual applications goes up exponentially with the amount of sharing we can do. The accessibility of the information gives a crappy interface connected to the web greater value than a fantastic – but lonely – user interface.
If we do value the connectedness of our data more than the interface in which its presented, then Google’s success with products like Docs, GMail, and Calendar are easily explained. That their interfaces happened to suck less than competing web applications merely gave them the leg up needed to take the majority of the market. So far.
Having And Eating Our Cake
Twitter shows us the future of the Web. The user interface on Twitter’s home page is as technologically up-to-date as any of Google’s applications: it’s a full-on CSS-styled, HTML-structured, JavaScript-driven, AJAX-enhanced web application. And it looks just as lackluster as GMail or Google Calendar. But Twitter isn’t about HTML and CSS – it’s about data and the APIs to access and manipulate it.
More than 70% of users on Twitter post from third-party applications that aren’t controlled by Twitter. Some of those applications are other services – sites like TwitterFeed that syndicate information pulled from other places on the web (this blog, included). Others are robots like JackBot, my Java IRC bot which tweets the topics of conversation for a channel I frequent.
Most, however, are specialized user interfaces, designed for humans to read, write, respond, dm, link, post pictures, and otherwise poke at their Twitter accounts. Each one is unique, and each one has specific features that particular users find the most useful for their purposes. Clients like TweetDeck target the power-tweeter with multiple columns and advanced features for multiple accounts. Other clients, like Tweetie, aim to provide a full-featured interface within the limits of a mobile device. Still other clients, like Blu (my personal choice), are full of fancy graphics and animations.
These applications successfully meld the web and the desktop. They harness the value of Web-connected data while in rich, interactive experiences. And its not just flash and bling. By leveraging their platform’s capabilities, each application can be tailored to the needs of its users, making it possible for each person to extract the most value from their data.
So if Twitter is the model for how Web applications should be written, then why aren’t we there yet? In the next post, I’ll discuss why we’re so far behind, and why I see Chromium OS as a step in the wrong direction for web-centric applications.