Won’t Someone Write a Decent E-mail Client?

Posted on Published by 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)

WikiWords Versus External Links

Posted on Published by Eugene Eric Kim

Suppose you are writing in a Wiki or WikiWord-enabled blog. Why would you use a WikiWord instead of an external link?    (3T)

For a more concrete scenario, consider a link to Blue Oxen Associates. You could either create an external link to http://www.blueoxen.org/, or you could use the WikiWord Blue Oxen Associates. I see several advantages to the latter:    (3U)

  • Easier to remember. Is it blueoxenassociates.com or boa.net? WikiWords are human-friendlier link names.    (3V)
  • Enter the link once. If your Wiki page includes the appropriate external link, and if that link changes, you only have to update the link once.    (3W)
  • Annotation. I often create Wiki pages to organizations that contain an external link and the contact information. Having the contact information on the Wiki page saves me from having to search the external site for that information.    (3X)
  • Backlinks. If you use a WikiWord, you inherit your Wiki’s Backlink functionality, which allows you to find other interesting and relevant pages.    (3Y)

The primary disadvantage occurs when the Wiki page simply consists of an external link. In this case, you force the user to click twice instead of once to get to the relevant information. I believe that this is offset by the other advantages of WikiWords.    (3Z)

Creating Motivation in Asynchronous Environments

Posted on Published by Eugene Eric Kim

I’m currently reading Leaping the Abyss: Putting Group Genius to Work, by Gayle Pergamit and Chris Peterson (who’s on our Advisory Board). The book is about the MGTaylor DesignShop process.    (2K)

Quick aside on MGTaylor: Founded by Matt and Gail Taylor, these folks have been around for almost 25 years, and are pioneers in facilitating what they call Group Genius. I had a chance to work with Gail and Matt at the recent PlaNetwork Conference, and came away in awe of their process.    (2L)

The MGTaylor process focuses on synchronous collaboration: same time, same place gatherings. Pergamit and Peterson write the following about the Design Shop experience:    (2M)

Without having attended the event — and discovered for ourselves both the costs imposed by some of our traditional procedures and the benefits that are possible within 72 hours — we would have remained curious, but not moved to action. (9)    (2N)

I had a similar experience at my first Dialogue Mapping workshop, taught by Jeff Conklin in July 2001. Prior to that workshop, I had read several of Jeff’s papers, and had come away with many interesting impressions of the IBIS grammar and the Dialogue Mapping methodology. However, those impressions were not motivation enough for me to try the process myself. One two-day workshop single-handedly created that motivation.    (2O)

I recently told this anecdote on our Collaboration Collaboratory mailing list, and suggested that synchronous collaboration was far superior at generating motivation than asynchronous collaboration.    (2P)

Is this true, and why? Are there patterns of asynchronous collaboration that excel at motivation?    (2Q)

I think it’s true. It’s simply a matter of show versus tell. When a group is sitting in the same room together, you can show whatever it is you want to show. When a group is dispersed, you can only tell them about whatever it is you want to show, and hope that they go and play.    (2R)

That said, I’m sure there are patterns of asynchronous collaboration for creating motivation; I just can’t think of many offhand. An obvious one is Tell A Friend — personal recommendations from people you trust. If my sisters recommend a book, I’m liable to read it. If my friends Justin and Cindy recommend a restaurant, I’m liable to try it.    (2S)

Grass Roots Peer Review

Posted on Published by Eugene Eric Kim

We had a Bay Area gathering of the Blue Oxen Associates Collaboration Collaboratory at Applewood’s Pizza in Menlo Park, California. Nine of us showed up, and we had a great time mixing and chatting.    (3P)

At one point in the evening, Brian Lincoln told Jon Cheyer his idea of Grass Roots Peer Review. They talked for a bit, and then Jon drew me into the conversation. Before we knew it, we were all discussing the idea,    (3Q)

Eventually, we started exploring a possible experiment that the collaboratory could perform. I posted a synopsis of that discussion on the tools-yak@collab list.    (3R)