The real problem with Mail Clients - Use Cases
July 9th, 2007Lots of People are talking about Brent’s recent article about the problems with mail. However there is an underlying problem that I think isn’t being addressed. E-mail has outgrown its physical metaphor.
Everything about the way that email and email clients are designed is based upon the physical metaphor of mail. Read this example, and tell me what I’m talking about, email or snail-mail:
You send mail to someone, they receive it. If it is junk, they throw it away, if its something they need to keep, they file it away.
Obviously that could apply to either. Now consider this one:
You send a message to Fred asking for his help with a problem with some software. He replies, what version do you use? You answer, version 2.1. He replies that you should upgrade to 2.1.1, which contains a fix for that problem. You send him a reply thanking him.
Now if you were doing this via snail-mail and you both live in the US, that entire exchange would have cost a total of $2.05 (assuming you’re not using post cards). Well you think, “It’s a good thing we have e-mail to handle things like that.” But is email as it currently stands really the best method for handling this use case? If you both use some form of IM, you could handle the exchange quicker that way, but some people don’t like things like IM or Twitter. So they only use email.
Now the problem with conversational bursts like the above, is that you probably don’t need to store them anywhere. Because you’re probably not ever going to need to reference that conversation again. However by default, mail stores everything. If you don’t file it, it is still stored until you explicitly delete it.
Another problem with conversational bursts is the waste of bandwidth (network and mental) and storage space. Imagine that you and Fred are vice presidents of some company or other. So you both have fancy email signatures. Your company is also the type that places little disclaimers on the bottom of the outgoing messages as they leave the server about the confidentiality of email, etc. So now you have something like this:
All of that, just to tell you to upgrade to version 2.1.1. Now obviously there are ways to shorten this, don’t quote the whole reply, don’t include your signature on the reply, etc… But most of these aren’t the default. The point is that conventional email doesn’t handle conversational bursts like this in an elegant way.
Finally imagine that you forward a conversation like this to someone else for reference. They have to first read your introductory text at the top, then go all the way to the bottom and read backwards to figure out what is going on.
So with all of the above in mind, here are some modifications/additions to conventional email use cases that I would like to see:
- Don’t keep anything unless I explicitly tell you to.
- Have a better method of dealing with short conversational bursts.
- Deal with quoting better (some version of code-folding comes to mind)
- Treat sigs like vcards, not as message text. (Sigs are after all just vcards without the markup)
Believe it or not, this is stuff that has been worked on a lot in Usenet newsreaders for a long time. That’s where the “dash-dash-space-return” convention for signatures came from, for example: Unison renders signatures that are prefixed with that standard prefix in light gray (and always generates signatures itself with that prefix), while Google Groups can elide them altogether. Similarly, Usenet is where a lot of the quoting conventions used in modern email came from, and Google Groups is at least smart enough to collapse quoted text unless it’s part of a back-and-forth exchange (e.g. inline quoting as opposed to full top-quoting or full bottom-quoting).