I signed up for Mailbox on the first day of its release and found myself sitting in line near position 280,000. As the number ahead of me has slowly wound down, and the number behind me has slowly grown, I’ve had a quite a bit of time to think about Mailbox, and what it really means.

There are more than three-quarters of a million people waiting for access to Mailbox. And since only a few people have actually used the app and can recommend it on the basis of its functionality, it seems that all those people are waiting in line for an idea, a cure for their email problem.

I haven’t used the app myself, but from what I’ve heard it is a tool to formalize the usage of Inbox Zero. Inbox Zero is a management philosophy for incoming email. As Merlin Mann, creator of Inbox Zero, explains:

Clearly, the problem of email overload is taking a toll on all our time, productivity, and sanity, mainly because most of us lack a cohesive system for processing our messages and converting them into appropriate actions as quickly as possible.

Inbox Zero proposes itself to be just that, a “cohesive system for processing our messages”, and Mailbox is the tool by which that system is accomplished. If Inbox Zero describes how to put together a house, Mailbox is the hammer and nails.

But not everyone agrees that the problem with email is that we lack a cohesive system. Paul Graham, in his essay on Frighteningly Ambitious Startup Ideas, says that the way to replace email, is to replace the inbox with a better todo list.

Email was not designed to be used the way we use it now. Email is not a messaging protocol. It’s a todo list. Or rather, my inbox is a todo list, and email is the way things get onto it.

One of his suggestions for email’s replacement is that it should give more power to the recipient.

I want there to be more restrictions on what someone can put on my todo list. And when someone can put something on my todo list, I want them to tell me more about what they want from me. Do they want me to do something beyond just reading some text? How important is it?

We already have some of the infrastructure in place in email itself to support what Graham is asking for. Specifically the “Importance” and “Reply-by” headers exist as defined in RFC 1327. As far as I can tell, those flags are largely unused. As Cory Doctorow notes (albeit on a different topic) in Epoch:

if you let a coder (or, ::shudder::, a user) specify the importance of her alert, give her a little pull-down menu that has choices ranging from “nice to know” to “white-hot urgent,” and nine times out of ten, she’ll choose “NOW NOW NOW URGENT ZOMGWEREALLGONNADIE!”

So, Boris from The Next Web took Graham’s suggestion one step further, and he requested additional metadata from his senders via his own personal InboxPro. This data allows him to easily address certain types of emails, like Yes/No questions, without asking questions about the priority of the message.

But do all these management systems and apps really solve the problem?

Put another way, what exactly is the problem?

  • Merlin Mann believes it is the lack of a cohesive system to manage incoming messages.

  • Paul Graham believes we’re using a messaging protocol where a todo list protocol would be better.

  • Boris believes we don’t have enough information about incoming messages before we manually parse them.

But could the problem be the sheer volume of email itself? The Slow Web Movement, a reaction against the increasingly real-time nature of the Web, seems to indicate that there are people who value not being beholden to the real-time paradigm. More and more, it seems that email is turning into a constant stream of incoming messages, and while it’s not real-time, it shares many of the same problems, and is antithetical to the Slow Web’s philosophy: “users should have a life.”

Every new email management app, and every new email management system seems to be treating a symptom of the disease rather than the disease itself. I’m not sure if the disease is the increasing amount of email, but I can be fairly certain that the disease is not the lack of a management system, nor a todo list communicated through messages.

Before we try to “fix email”, let’s figure out what’s wrong with it. Let’s diagnose the disease.