(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.

Long-time consumers of my site might remember a four-part series from 2006 entitled “What Does ‘Web Paradigm’ Mean, Anyway?”  In Part 1, I described how the web browser has been struggling – and mostly failing – to replicate the desktop user’s experience.  That’s not what the Web was designed for.

Notice that web applications have always striven to behave more like desktop applications. Since the very beginning, any web application of any complexity yearned to present a stateful, responsive, user-driven application flow. Sessions, cookies, and Javascript were all created with this in mind. Witness the advent of Ajax as the latest effort in this campaign to make the web more like the desktop. It’s the next logical step in a path that began with the <form> element all those years ago.

In Part 2, I took the path of the web browser as the canonical application platform to its logical conclusion – complete reinvention of the operating system – and discussed the folly of re-implementing decades of established engineering.

In the short-term, it allows for a quick path to closer web integration. In the long-term, however, it leads you down a slippery slope, demanding the question, “How far do you take it?” An IRC plugin may as well connect to AIM, Y!, and MSN. It’s only a short step from a peer-to-peer application to an Apache extension. After that, why not integrate file-level security and access control into your browser? With all of these different plugins, though, we can’t allow one malicious or buggy extension to monopolize the browser’s resources; so we’ll need to write a fair preemptive scheduler and memory manager.

In Part 3, I charted a path that allows us to combine the Web’s strengths with the Desktop’s strength’s.

There must be things we can do to more effective use the web in our daily lives than Firefox and Internet Explorer, right? We’ve taken pretty good advantage of the hyperlink, but can we finally take full advantage of the common languages and ubiquitous protocols, the final two things the web offers to us?

Finally, in Part 4, I gave some examples of how that might work, and what kind of platform and tools we need to make it happen.

We need a platform, independent of any particular application, that makes obtaining, parsing, transforming, aggregating, and forwarding XML as natural as displaying a window. Web integration needs to be a first-class citizen.

Projects like XULRunner are very strong steps in that direction. Microsoft is getting awfully close with .NET 2.0, and maybe we’ll see the first real platform in this space with Vista and WinFX. Finally, like Firefox, the ideas behind Smart Clients and Java Web Start are a good intermediate step, but they are not the future.

So, four years later, how are we doing?  We’ve made some bold steps in the right direction, but we have yet to fully harness the potential of the web in our daily experience.  In my next post, I’ll talk about the limitations of the status quo, and the model we should strive to emulate.

I’ve created a webapp bundle that does just that.  Unfortunately, such bundles at present only work with the stand-alone version of Prism.  The Firefox add-on is really a better way to run Prism, but if you’re using it you’ll need to do a little manual mucking in your webapp profile to use this bundle.

Stand-Alone Bundle

So, if you just want the bundle, here you go.  Note that I haven’t really tested it on the stand-alone version, so please let me know if something is broken.

Hack Your Webapp

As I said, if you’re using the add-on version, you’ll need to do a little manual hacking.  After you create the webapp, as described in my earlier post, open up Explorer and navigate to your Prism webapp bundle cache.  On Windows, this is in %APPDATA%\WebApps (something like C:\Users\Brian\AppData\Roaming\WebApps); on Linux, it is ~/.webapps.  You should see your Google Wave webapp in that directory.  Add the webapp.js script to that directory, and also add in images/google-wave-52×32.png.  Now you should get a toaster pop-up and task bar notification when there are new waves.

It would be nice if Google were to add a <link rel=”webapp”> to Wave, referencing an appropriate bundle.  If anybody there sees this and cares to use my code as a crude starting point, I am releasing this code under an MIT license.

This thing screams for its own window.

That’s where Prism comes in.  Prism allows web applications to be run in a separate browser process, complete with a separate profile, their own window, and a unique taskbar icon.  For long-lived applications like a calendar or a chat tool, this is far more useful and stable than opening yet-another tab.  Furthermore, I like to read web pages in a tall window (roughly the same proportions as an 8.5×11 piece of paper), but I prefer my communications tools in a wide window.  Prism let’s me easily size Wave however I’d like.

After you install the add-on and restart Firefox, just navigate to Wave, click on the Tools menu in Firefox, and click Convert Website To Application.  You’ll want to cut out the cruft from the end of the URL, leaving just https://wave.google.com/wave/.  And it’s usually helpful to leave the status bar in place.  If you’d prefer to have wave in the system tray, you can check that box here, too.

You’ll also want to pick a different icon – especially if you’re on Windows 7.  The default favicon.ico that Prism auto-downloads is very small, and scales up really poorly.  Here’s a 256×256 one that I used as a PNG and as an ICO.  It looks great in my task bar.

I also use Prism with Google Calendar and Toodledo, and love it.  And I’m about thiiiis close to pulling Google Docs into it as well.