How Email Will Supplant Desktop Apps

(In which your author mocks a pervasive and wrong belief about the future of the Internet.)

Many people believe that the Age of the Internet necessitates the passing of the Age of the Desktop Application, in the same way that the Age of the Desktop Computer heralded the end of the Age of the Mainframe.

This brings up three questions: why, what, and how?

The first question is the easiest. A desktop application requires that you find the software, obtain the software, install the software, and then learn how to use the software. There may be licensing fees or a difficult installation process or compilation or cursing when you discover that the binary doesn't work on your operating system. If you can get past all of that, you may discover that the brilliant User Interface with bells, whistles, widgets, and themes may not only be ugly as sin but also impossible to use correctly.

Then try sharing work you create in that application with other people, or using it on your smart phone, or accessing it from a different computer.

Given that the Internet is a global, loosely-connected, fault-tolerant, distributed network of more computing power than you can imagine, it makes sense to move at least some of that processing (and certainly the data storage) to somewhere you can access it from any Internet-connected machine.

The magic is figuring out the right kind of interface makes the most sense and can scale from desktop to laptop to kiosk to tablet to smart phone.

That right kind of interface is simple e-mail.

E-mail relies on all of the good parts of SMTP: it's widely distributed, it's federated, it has a store-and-forward system, it's an open standard, and there are countless clients (for humans and machines) capable of understanding it.

Not convinced? Imagine commenting on this article via e-mail. You read it in your favorite mail client. You hit Reply. You type your comments and hit Send. That's it.

You don't have to muck around with logging in or creating an account (you already have one). You don't have to worry if my server configuration or a web gateway in between us will silently drop your message. You don't have to wonder if you need to re-enable JavaScript to solve a CAPTCHA and hope that the mandatory refresh won't destroy your carefully typed submission. If you decide you want to save your comment for later, hit Save as Draft and come back to it an hour, a day, a week, a year later.

Some might say that a plain-text medium is insufficient for all of the graphical goodness necessary in a modern application. That's bunkum; plain-text e-maill supports text areas natively, as well as text boxes, combo boxes, and buttons:

Name: ______________ (textbox)

Medical history:




(textarea)

Age (choose one):
    ( ) Under 18
    ( ) 19 - 25
    ( ) 26 - 39
    ( ) 40 and older (combobox)

Preferred pie flavors (choose many):
    [ ] Berry
    [ ] Peach
    [ ] Apple
    [ ] Pudding
    [x] Strawberry/Rhubarb

Mac users may appreciate that it's possible to manipulate graphics even in plain text. Including a complete demonstration of PhotoShop-quality output would bloat this essay, but for a hint please see Programming Sprites - Another Look.

Privacy- and identity-minded individuals will be glad to note that well-configured e-mail systems support both modes of operation. SMTP does not require strong identification of senders, but it can support strong identification. In particular, if your outgoing mail server requires authentication, it can attest with some authority that a message purporting to be from you is indeed from you (thus solving the identity management problem inherent in other protocols, such as HTTP). If you wish to use the Internet more privately, simply disable this identification system in your outgoing server. (Perhaps a clever e-mail client could offer a mechanism to toggle secure/anonymous mode.)

I could wax poetic about all of the other benefits of this system, but two of the most compelling are the composability of client and server-side operations as well as offline mode. The latter is easiest to understand: you can batch client-side operations when you do not have easy access to the Internet at large and submit them only when bandwidth is available. At the same time, you may receive batched responses from previous requests. You do not have to be online with an active connection to continue to perform useful background and foreground work!

Composability sounds trickier, but you likely already perform it. I have access to my incoming mail server, where I use Email::Filter to categorize all of the Internet applications I use through SMTP through the use of organizational tags, based on message content. For example, all of my work programming the Parrot virtual machine is available under the folksonomic tag "p6i". Please note that this occurs via analysis of incoming communications based on characteristics I've noticed; this tag is of my own invention and is neither a feature of the application on the server side, nor normative behavior of other users of the application. I have the freedom and flexibility to manage my own tags as I see fit.

Another clever feature on my incoming server is the ability to combine several incoming messages into a single message, thus filtering out duplicates.

Of course, it's easy to write server-side applications as well. I wrote the underused Mail::Action software several years ago and have used it productively ever since.

I should note one potential (though solveable!) drawback with the use of pervasive plain-text e-mail as the replacement for desktop applications: it does often require (at least for now) the use of a client-side desktop application which can send and receive e-mail. In the future, e-mail-only devices such as the Blackberry may grow more common (I shouldn't have to mention how much easier it is to archive the textual transcript of a conversation than an unrecorded phone call!).

Some users may require persuasion to leave webmail systems for the more powerful and future-proof desktop clients suitable for unlocking the full range of applications made possible by pervasive SMTP. This may be difficult, but the result is inevitable. No one sane could possibly believe that a web browser would make an effective universal desktop client.