eekim.com: EEK Speaks

Sat, Jul 26, 2003

Won't Someone Write a Decent E-mail Client? #

BrianLincoln was complaining about e-mail clients recently, and he said that he was willing to pay $1,000 for a good e-mail management tool. That's a stunning statement, if you think about it. E-mail is probably more widely used than word processing, and probably ranks near even with Web browsing. Several companies have devoted large budgets to building e-mail clients, and there are several open source initiatives as well. You would think that there would at least be once decent e-mail client by now. (40)

Despite all of this, I completely agree with Brian. I haven't found anything that comes close to doing even mostly what I want. (41)

(I have to throw in a brief disclaimer about mutt, which I've been using for about a year. Mutt is very customizable, which I like very much, and is fairly UNIXy, which I also like. It's supposed to be easily extensible, but I haven't had a chance to test this myself. At some point, I will.) (42)

I get tons of e-mail. I save a large percentage of it, including e-mail that I send. My archives date back to 1994. There's a wealth of information there, and I'd like to be able to easily retrieve what I need when I need it. I want: (43)

Powerful search capabilities. (44)
Categorization. (45)
Ability to link e-mails with other types of information: calendar, datebook, Web pages, source code, other e-mails, etc. (46)
Useful views. (47)

I'm not going to expand on these here, except to say that doing all of this stuff right has significant architectural ramifications. One reason I may be so difficult to please in this regard is that I have fairly well thought-out ideas on what that architecture should be, and I have yet to see this kind of architecture in any tool. I was heavily influenced in this regard by Doug Engelbart, who's also on our Advisory Board. (Some of these thoughts are loosely captured in my paper, "Towards a Standard Graph-Based Data Model for the Open Hyperdocument System", which Ken Holman presented for me at Extreme Markup 2002.) (48)

The e-mail tool whose architecture comes closest to my vision is Helium, a class project at Indiana University that emerged out of Gregory Rawlins's KnownSpace in Fall 2002. Using KnownSpace? as its data architecture, the team explored and prototyped a lot of interesting ideas. Unfortunately, there are limits to what a team of students can accomplish in a semester, and the project is unfinished and in stasis. (49)

Chandler holds a similar appeal as Helium, as I explained to the Collaboration Collaboratory last January. (4A)

Here are some other pet peeves regarding today's e-mail clients: (4B)

HTML e-mail. If you're going to use it, at least implement it consistently. (4C)
Moronic word-wrapping and line lengths. More evidence of widespread disinterest in interoperating well with other e-mail clients. (4D)
Reply-to behavior. Most users have no conception of the "To" header. They hit their "Reply" button, and simply expect the e-mail to go to the right place. This is a solvable usability challenge, but somebody needs to tackle it. (4E)
Quoting. How difficult would it be to come up with a standard for quoting other e-mails? More importantly, wouldn't it be great if people could send one-word responses to e-mails without citing an entire three-month thread at the end of the message? (4F)
Header control. Most e-mail clients hide headers by default. That's okay. But sometimes, there's valuable information in the headers. Many e-mail clients make it extremely hard to view this information, or to forward it to other people. (4G)
Folder management. Blech. Folders are not a good way to categorize e-mail. The first vendor who figures this out is going to make a lot of money. (4H)

/tech/email | Posted at 11:22am

Comments

Comments disabled until future notice. If you'd like to contact me, use my i-name (=eekim).

EEK Speaks

A blog about collaboration, community-building, and the various goings-on at Blue Oxen Associates, with occasional digressions on food and other vital matters.