Merlin Mann, the creator of Inbox Zero, has some truly excellent advice on how to think about your email, your inbox, and yourself. In particular, not feeling guilty about deleting messages or sending terse, one-line-replies are golden rules. Not to put too fine a point on this, but I agree without reservation with the principles and practices of Inbox Zero.
I believe that Inbox Zero is a human operational method for dealing with fundamental shortcomings in the software we are forced to use. The very fact that we have an “Inbox problem” is prima facie evidence that the software bringing our email to us isn’t really designed with our goals in mind.Email programs are a classic example of what I call implementation model software. Software that presents the user with a close analog of the mechanism used to implement it is an implementation model design. From a technical point of view, email is little snippets of ASCII text arriving at our computers in a serial stream. Human-facing email programs then present to us an inbox, which is a serial stream of little snippets of ASCII text.
We are all so intensely familiar with the inbox, and it even has a nice, metaphoric tie to physical objects from our pre-digital desktops, that we take its existence for granted. But its existence depended on the way atom-based communications worked in the centuries preceding our digital one. Aside from oft-repeated convention, there is really no good reason for presenting email to humans this way.
Almost all email is actually part of a conversation. I say something to you. You say something to me in response. Our little exchange maybe implemented as little snippets of ASCII, but it has no connection with all of the dozens (hundreds) of other little snippets relating to other conversations with our other correspondents. Unfortunately, the inbox combines all of those messages from their many disparate sources into a single place, organizing them only by their time of arrival, which is not really all that important in the grand scheme of things.
Now, threaded conversations are not a new idea, and Gmail has blessed us with some mighty fine tools for managing threads. But even Gmail persists in presenting it all to us as a, wait for it, serial stream of little snippets of ASCII text.
I think it would be much better if we could see our various conversations graphically and spatially, instead of textually and serially. If I send you an email, it should appear to me as a visual icon, floating on that part of my screen where all of my recently-begun conversations float. When you eventually reply, your response should appear as a moon orbiting that visual icon; small and clickable to read, and moving to attract my attention.
Let’s say that you originated a conversation with me instead. Because I know you (you are in my contact list), the software would put an attention-getting visual icon up in the area where new conversations from people I know are placed. By clicking on that icon, I can reply directly. As our conversation continues, more moons would appear adjacent to the original icon; orbiting until they are read, then docked quiescently afterwards.
Conversations that lie dormant slowly fade from bright to dim to gray, eventually disappearing. At any time, I can flag the conversation so that it will be permanently archived when it disappears, but the normal destination would be the bit-bucket. This means that I don’t have to manually empty my inbox. My inbox would be smart enough to do it for me.
Emails sent to me by people who are not in my contact list would be relegated to a different place with a different visual representation. You know, there is a role for a conventional inbox. But these messages are naturally, appropriately, given a second-class presentation (which they deserve) compared to the first-class presentation of communications from my known circle of correspondents (which they deserve). This is a remarkably simple anti-spam strategy: promote the known good stuff (which is a technical no-brainer) instead of trying to identify the unknown bad stuff (which is technically extremely difficult).
I’m willing to acknowledge that creating email software that works as I’ve described here would be a fairly big project, beyond the scope of even those few experts with the skills to build it. I’m willing to acknowledge the fact that alternatively applying the manual steps of a practice such as Inbox Zero have a low barrier to entry and are imminently practical. But I think it is vitally important to also acknowledge that such behavior is compensating for the bad design of the software tools we use.
It is so exciting to be able to do new things with cool new technology that we rush ahead to new green fields of accomplishment before we ever create good quality products in the old fields. In other words, we never really got email right, so instead we developed SMS, Twitter, Facebook, chat, ad infinitum. The craftsman in me rebels at this.
I don’t believe that email is the ultimate communications medium, nor do I believe there is anything wrong having other, different modes of digital communication. I simply believe that we owe it to ourselves to put design effort into email that is commensurate with the amount of time and consideration that email plays in our lives. While devising mental strategies to cope with the toxic and unhelpful behavior of poorly designed software works, it puts the burden on the wrong party. It is a blame-the-victim strategy. It pains me to see so much that in the world of software.