What Does “Web Paradigm” Mean, Anyway? (Part 2)

In the first post on “What Does ‘Web Paradigm’ Mean, Anyway?”, we discussed the ideas of bringing the web into the desktop, and bringing the desktop to the web. I have taken the position that melding “user interface innovations pioneered in the web browser” with the desktop will not dramatically alter how we use our computers because it has already occurred. The modern user interfaces have already taken what is useful from the web, at least to the extent the technology allows.

And what is that, precisely? As I stated previously, the web is really only good for a few things, namely: cross-network links, common languages, and ubiquitous protocols. The modern desktop metaphor has been under constant revision since its creation in the late 1970s, and has some thirty years of expert research and implementation guiding its implementors towards effective human-computer interaction. The only real item adopted by the desktop user interface is the hyperlink. Finally, arbitrary textual and non-textual information on the screen can be associated with further and/or related information in an obvious, efficient manner. The need for a bulky button or clumsy tree has been obviated by simple highlighting and underlining.

So with this integration of the web and desktop, the desktop got hyperlinks. Simply opening a web browser when one clicks on a hyperlink on an error message is a good first step, but where do we go from here? The revolution seems to have missed out on the other two innovations the web provides. In its current form, the desktop only makes simplistic use of the web’s common protocols and languages. Sure, we can display HTML pages wherever we’d like, but HTML pages suck. As Steve Maine points out, even with modern techniques like Ajax, the web will always be behind the user-interface curve. It’s simply a matter of horsepower.

How can we seemlessly bind the vast corpus of data that is the web into our everyday workflow? One possibility, as suggested by the AllPeers blog, is to move our applications into the browser. Since the web browser is the central experience required for today’s web, we can attain better functionality by moving our programs closer to the core. Firefox extensions provide a very powerful, very simple manner for doing so. Unfortunately, this approach is a dead end.

In the case of Firefox, there are plenty of precedents for extensions that offer communication capabilities that have nothing to do with the web: FireFTP and Chatzilla, for example. So if I’m off my rocker, at least I’m not alone. If people find it convenient to have all their browsing happen in one place, with a consistent usage paradigm, why limit this arbitrarily to the web?

I do not think the AllPeers fellows are off their rockers, nor do I feel the same about Chatzilla or FireFTP. 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. The end result is writing an operating system!

It was widely rumored that fear of this very occurance was one of the major factors prompting Microsoft to finally enter the Internet age, eventually snuffing out almost all rival browsers in their bid to maintain Windows as the only real platform. Imagine if Netscape had taken over the world: The differences between Windows, OS X, and Linux would not make a lick of difference as long as your software was compitable with the latest Netscape web browser. The idea is similar to Java, .NET, and XULRunner - a runtime platform commoditizes the underlying operating system and hardware by increasing the level of abstraction and improving productivity for certain specific programming tasks. The irony of moving all our applications into the web browser is the eventual demise of the web browser. If the browser becomes the platform, then there is no browser.

The worst part is not the requisite attempt at re-implementing sixty years of operating systems, with all the security problems, interface issues, and compatibility problems that such an endevour would entail. No - the worst part is that we’re stuck with HTML as our primary user interface. Different programs have different usage paradigms. The web browser is very good at browsing the web, and Trillian is fantastic as a chat program. Thunderbird’s interface is taylored specifically for email, and OpenOffice Writer is geared towards writing full-fledged documents. To assume that a “consistent usage paradigm” has been arbitrarily limited to the web belies an ignorance of just how generally ill-suited HTML, JavaScript, and the ilk are for producing useful systems.

Before I get flamed, please remember: I am not saying that it isn’t possible, nor am I stating that it has never been done. I am certainly not saying there is no value in web applications. I am saying that it is inordinately difficult to produce desktop-quality applications in a web browser. Enhanced browser platforms cannot make this significantly eaiser because they have been specifically designed for rendering HTML and web browsing. Firefox extensions should remain just that - extensions to the browsing experience.

If the browser becomes the platform, it will always be behind the technology curve, burdened with an interface limited by the design intent to display web pages. If you try to make it more, you’ve re-created the most insecure-by-design plugin system ever to rear its head. It’s a dead-end, and it just won’t happen over the long haul.

So we return to the question with which we began: Where do we go from here? How can we seemlessly bind the web into our everyday workflow? How can we achieve tighter web integration without limiting ourselves to a dead-end platform? More on that next time.

(I apologize for this post being a day later than I promised. Life is always busier than it should be.)