Eugene Eric Kim

Brian Lincoln 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 Known Space 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)