Email's many hats

But even though email isn't the best tool for any of these tasks, it provides a single interface to all of them. Here's a challenge: let's improve the various functions performed by email without multiplying the interfaces people must learn in order to use those functions.

Consider file transfer. It drives me nuts when people send me multi-megabyte files as email attachments. Don't they know a better way? Heck, there are easily a dozen methods available to me. Depending on the situation I might use FTP, HTTP file upload, WebDAV (web distributed authoring and versioning) or scp (for encrypted file transfers) to post a file to a server. Or I might drop the file into my Radio UserLand upload directory, which does FTP automatically. Or I might send the file directly through Windows Messenger, AOL or iChat. Or I might drop it into a Groove shared space and let synchronisation take care of the transfer. With all these choices, why do people fall back on the common denominator of email attachment?

The problem, of course, is that there are so many choices. Those of us who are technically inclined have long since internalised them. But mastery of multiple interfaces goes way beyond the call of duty for most folks. Email is a poor file-transfer solution in many ways, but it makes perfect sense to users. An email with an attachment compresses notification and delivery into a single step. When I use one of my alternate methods, it's a two-step dance. I still send a notification message, in this case containing just an URL. Separately, I upload the file pointed to by the URL. It's second nature for me, but most people won't want to do that two-step, and they shouldn't have to.

I'm hardly the first to imagine an interface-conserving solution. An email client could pass a file "by reference" rather than "by value", automatically uploading the file and transmitting only its URL. If the file is confidential, the program could upload it to a password-protected directory and include the password in the message. If it's really confidential the file should be encrypted, but that's an obscure part of email's interface that few have mastered.

Mailing lists and newsletters present an analogous opportunity. As I've often noted, RSS simply makes obsolete the use of email for these purposes. Inherently opt-in and spam-free, RSS spares both senders and receivers the cost and hassle of trying to keep the email channel of communication clear. So why hasn't RSS been adopted more widely for this purpose? It's no mystery: an RSS reader usually presents a new kind of interface. But that's not necessarily so. NewsGator, the RSS newsreader that runs as an Outlook plug-in, is a great example of interface conservation. When you subscribe to a feed in NewsGator, it looks like any other source of email messages. But this source is unlikely to spam you. And if it does, you can tell it to go away and it has no choice but to comply.

I'm not saying we shouldn't invent new interface genres. Arguably there's too little of that kind of innovation. But we can innovate within established genres, too. If better implementations of email's various functions can retain the comfortable familiarity of email's interface, let's have them.

Udell is lead analyst for the InfoWorld Test Center.