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).