How Email Programs Fail

How Email Programs Fail

While vendors wage pitched battles in the software markets, users cower in their cubicles, fearful of wandering into no-man's-land. Email vendors , for example, add feature after feature to their checklists while still failing to address the fundamental needs of electronic communications.

New users of email are entranced by their novel ability to communicate directly, simply, and asynchronously with anyone else. But solving the tasks doesn't necessarily solve the user 's goals, and that is why emailing remains in its primitive state. The problem lies in the misunderstanding of what email is really used for. Twenty years ago, getting any email was an important event. Because the medium made it clear that the message was important, the message itself wasn't anything special. In fact, it was just a simple, discrete file of plain ASCII characters with no special characteristics or relationships.

Today, we get a broad mixture of important and worthless emails. Any person who uses email discovers quickly what a powerful and useful medium it is, and her use of it rapidly escalates until she is running a significant part of her life and business on it. Many email users get dozens or hundreds of email messages every day. Most communications are sent either in response to some message, or in expectation of a reply. These sequences of messages, called threads, bounce back and forth between two or more people. On my computer, the ratio of threaded messages to singletons is about 50 to 1. And yet not a single email program available today treats email messages as part of a sequence. ^[1] They act as though threads either don't exist or are an insignificant attribute of only a few emails.

^[1] Some email programs let the user manually construct and manage a thread, but the cure is worse than the disease. Managing the feature is difficult, and threaded conversations are still treated as exceptional.

It is easy to understand that viewing threads instead of messages lets the user clearly see the connections and flow between individual messages and how they form coherent conversations. When examined from a task or feature point of view, all you can see is that you need to either send or reply.

It is not a particularly difficult programming problem to handle email as a series of threaded conversations; it is just that it has never been done that way, and programmers are reluctant to innovate on the user's behalf and managers are fearful of forcing them down that unproven path .

Because the programmers view the software from the point of view of implementation, they see that messages are flowing back and forth and that users can put messages into folders, so the programmers don't see a problem. After they get the bear moving, they declare it a dance and cease any further instruction.

Email is only one example of software products that don't achieve the simple and obvious goals that they should. We are so impressed by the dancing bears that we fail to see the inadequacy of these products. Here are a few other examples.