Problems With Email

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

Lack of Context {nid GM}

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. {nid GN}

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

Threads Are Poor at Organizing Information {nid H5}

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. {nid H6}

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. {nid H7}

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 JoshTyler 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. {nid H8}

There are attempts at presenting threads in a useful way. The best is KaPingYee'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.) {nid HZ}

One suggestion that I've heard repeatedly (most recently from MattSchneider's post on the CollaborationCollaboratory) 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 LeftHandMove.) This undermines the assumption that an IBIS-constrained e-mail discussion will result in an organized record.) {nid I0}

Discursive Discourse {nid GP}

tyranny of the vocal. MarkTwain: "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.) {nid IY}

parallel threads -- switching context in any given timeslice. (ProblemsWithEmail#H7) {nid H9}

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 SheldonChang'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. {nid HU}

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. {nid HV}

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. {nid IZ}

No Memory {nid VK}

See SebPaquet'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. {nid VL}

Why is memory important? JerryMichalski touched on this at his December 2003 GivingSpace workshop talk. As I explained in my blog entry on the workshop: {nid VM}

[t NE] {nid VN}

E-mail Clients Stink By Default {nid ID}

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

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. {nid IF}

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 SurvivalOfTheFittest 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. {nid IG}

Other References {nid GQ}

• EricArmstrong, "What's Wrong with Email?" {nid GR}
• ReMail {nid JJ}
• GinaVenolia's work at Microsoft Research {nid OB}
• Two tools that attempt to convert email archives into a more useful knowledge repository are ZOE and Emila {nid W4}