|stating the obvious||archives | about|
More Life Beyond the Browser
Lately I've been hearing a lot of discussion about "the other half" (even though it's much less than half) of American households that aren't online, and what's going to convince people to plunk down so many dollars for connectivity every month. "Where is the killer app?" they ask.
Of course the obvious answer is email, for a whole host of reasons: it's personal, it's fast, it's a metaphor that people can easily get their arms around. Plus, the more people that have it, the more people that want it. It's the simple law of networks.
But what I believe will keep email on the top of the "killer app" list is not just the functionality it brings, but the many different ways users can take advantage of its functionality. Leaving aside the content for a moment, POP and SMTP services are the perfect network services because they allow the end user an inordinate amount of flexibility in choosing the way they want to manage their mail.
Pine. Elm. Eudora. Communicator. Outlook. Claris Emailer. Pegasus. AOL's mail client. E-Corp's Email97. Not to mention all of the corporate solutions -- Notes, cc:mail, MS Mail, etc., etc., etc. POP and SMTP are so straightforward that the market can provide dozens of different front-end solutions for every different type of user. From the bare bones simplicity of Pine to the dozens of filters programmed into Eudora, the elegance of the server-side implementation allows for an incredible degree of flexibility on the client side.
Imagine if there were the variety in web browsers that there currently is in email clients. Not that I'm terribly disappointed in the offerings from Netscape and Microsoft, but not enough control over the way that sites are experienced is left to the end user. The browser forces a specific way of thinking on the way you use the Internet. Theoretically, HTML and HTTP should operate like POP and SMTP, and the market should be wide open for different models of pulling information from a website. The reality, however, is much different, thanks to browser-specific code, an emphasis on page layout instead of information design, and an net-wide lack of informative metadata.
That's not to say there's not hope for different methods of gathering information off the net. While not "browsers" per se, there are three products which have broken the browser mold quite well. They're worth exploring, if only to see what's possible when you rid yourself of the forward/back/home mentality.
The NewBot search tool from Wired and Inktomi.
While each of NewBot's features could have been implemented in a browser model, the NewBot tool smartly takes advantage of local processing power to do things like storing search terms and sorting search results. And even though certain elements of the UI just scream VB/Active-X, it's still an elegant solution to the "10,000 hits" problem.
"You Don't Know Jack, the netshow" from Bezerk and Berkeley Systems
Berkeley could have done a promotional site that uses the Riddler model, feeding us the "irreverent" tone of the game via a traditional browser. Instead, they broke the browser and implemented a true-to-game teaser. In doing so, they also broke the traditional advertising model...the netshow is sponsored by interstitial ads that are full-screen, animated "spots" with sound. Advertisers must love it.
Quake, from id Software.
While the whole trend of browser vs. non-browser applications is wrapped up in the titanic war over fat and thin clients, and while Netscape and Microsoft have a vested interest in having their browsers be the one and only front end to web content, I still believe there is a place for more creative approaches to life on the client side. It's the "right tool for the job" argument: if a task can be done more effectively with a small, fast piece of code that resides on the client, then why not?
The dozens of email clients that are available should be some indication of the possibilities for Internet apps that break the browser mold and take a fresh approach to interacting with server-side information. The true killer app should serve as an example for developers of the next set of killer apps.
Other pieces about client-side software: