Problems With Email

Most (but not all) of these complaints also apply to threaded forums (USENET, Web-based bulletin boards, etc.).

Lack of Context

Context in e-mail generally appears as quoting entire threads. When there are long, rapid-fire threads occurring in parallel, maintaining context is challenging. Generally, we accomplish it by maintaining the context in our heads. Those of us who are capable of switching focus rapidly are better suited for these types of conversations than others.

We can alleviate this contextual problem to some extent by using tools: filtering combined with a good threaded mail reader, for example.

Threads Are Poor at Organizing Information

A threaded view of an e-mail discussion does very little other than to show that some topic (presumably specified in the Subject header of the first message) seems to have generated some amount of discussion. It reveals neither the nature of the discussion, nor even the depth or quality of a discussion. A "bushy" thread could indicate deep, thoughtful discourse, or it could be two people tossing inside jokes back and forth. It could be a group of people trying to schedule a meeting or deciding where to go to dinner. In the first case -- deep discourse -- the important discussion may actually be embedded in a sub-tree of the thread. However, from the thread view alone, it is impossible to determine which sub-tree is the discussion you want to follow, and which sub-tree is the debate over the dinner destination.

Threads do have value. Ironically, they are valuable for organizing a conversation linearly. But, they're not ideal at this either. People usually read their e-mail as it comes in (chronologically). In responding to an e-mail, they may implicitly refer to an e-mail that arrived earlier but appears later in the thread tree. That link is rarely explicit, although it could be captured by combining a thread view with a time axis.

Threads can also be used for identifying social networks within a community -- by analyzing who's responding to whom. This is great for researchers like me, and it may have real value for organizations. (See Josh Tyler et al's "Email As Spectroscopy: Automated Discovery of Community Structure within Organizations.") But, it helps little when it comes to finding the knowledge you're seeking.

There are attempts at presenting threads in a useful way. The best is Ka-Ping Yee's zest. The Mariachi mailing list archiver (part of Siesta project) has been hacked to do something similar. IBM's ReMail project also has some interesting visualizations. (Richard Clamp has implemented this visualization in Perl, and has screenshots.)

One suggestion that I've heard repeatedly (most recently from Collab:Matt Schneider's post on the Collaboration Collaboratory) is to use e-mail to have IBIS-like discussions. The motivation is to create a more useful, organized archive, with views similar/superior to the ones cited above. It would require users to be very disciplined about posting -- specifying a node type, creating a good node label, figuring out where the node should go, limiting e-mails (nodes) to a single idea. This is why it won't work. The other reason is that good IBIS maps depend heavily on refactoring. (Consider, for example, the Collab:Left-Hand Move.) This undermines the assumption that an IBIS-constrained e-mail discussion will result in an organized record.)

Discursive Discourse

tyranny of the vocal. Mark Twain: "I didn't have time to write a short letter, so I wrote a long one instead." (Maybe call Abelard Twain instead? Twain was a great letter writer.)

parallel threads -- switching context in any given timeslice. (Problems With Email#H7)

Occurs because e-mail doesn't enforce rhythms. That's what makes e-mail a great all-purpose collaboration tool, and why it can be used in so many ways (for example, as instant messenging; see Sheldon Chang's post). Used effectively in a group context, most people are using it in the same or complementary ways. When not effective, some people view usage as occupational spam. For example, an almost real-time interaction can be energizing for a few people, but it may just end up driving others from the group.

How do you balance this? Understand what patterns e-mail facilitates (and that you want to facilitate), and use a suite of interoperable tools that facilitate those patterns.

discourages refactoring. People follow e-mail as it comes in; once read, they normally file it away (possibly in the round file) and forget about it. No one cares about refactoring, because no one is paying much attention to the leftover artifact.

No Memory

See Seb Paquet's blog, "Email is where knowledge goes to die." One problem with email -- by default, there is no memory. People don't necessarily save their email. That makes it impossible to refer back to or to share it with others.

E-mail Clients Stink By Default

(For a more general complaint about e-mail clients, see my blog entry, "Won't Someone Write a Decent E-mail Client?".)

The default view of most e-mail clients is a chronological one. That's okay for most purposes, but for mailing lists, you need something better -- at minimum, a standard threaded view. If you have multiple lists, you need a good filtering mechanism to truly optimize your e-mail experience.

The problem is, most users don't know how to use these features, so they don't, and their e-mail experience is suboptimal. Some people can handle large volumes of e-mail quite effectively using these tools. These folks don't mix as well with those who don't handle large volumes of e-mail well, for obvious reasons. This Survival Of The Fittest effect serves to exclude a segment of the community that might have something very valuable to contribute, but simply can't deal with high volumes of e-mail.

Other References

• Eric Armstrong, "What's Wrong with Email?"
• ReMail
• Gina Venolia's work at Microsoft Research