E-mail’s many hats

E-mail is the jack of all trades, but the master of none. There are better ways to transfer files, hold discussions, deliver notifications, broadcast newsletters, schedule meetings, work collaboratively, and manage personal information. But even though e-mail 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 e-mail without multiplying the interfaces people must learn in order to use those functions.

Free IT resource TechNet: More ways to know it, share it, and keep it running. Sponsored by Microsoft Free IT resource Attend the SOA Executive Forum: Breaking SOA Bottlenecks SOAExecForum.com/may2007 Sponsored by InfoWorld

Consider file transfer. It drives me nuts when people send me multi-megabyte files as e-mail 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 synchronization take care of the transfer. With all these choices, why do people fall back on the common denominator of e-mail attachment?

The problem, of course, is that there are so many choices. Those of us who are technically inclined have long since internalized them. But mastery of multiple interfaces goes way beyond the call of duty for most folks. E-mail is a poor file-transfer solution in many ways, but it makes perfect sense to users. An e-mail 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 e-mail 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 reallyconfidential the file should be encrypted, but that's an obscure part of e-mail'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 e-mail for these purposes. Inherently opt-in and spam-free, RSS spares both senders and receivers the cost and hassle of trying to keep the e-mail 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 e-mail 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 e-mail's various functions can retain the comfortable familiarity of e-mail's interface, let's have them.