Revolutionizing the Display of Incoming and Outgoing Messages in Email Clients like Thunderbird
What’s the Problem?
When you want to read a bygone mail conversation again, you have to repeatedly switch between the folders „Inbox“ and „Sent“, back and forth. Why can’t all those message reside in one single folder?
In other words: Why do the standard folders (Inbox, Unsent, Drafts, Sent) work completely different than custom folders? In any custom folder, you have both incoming and outgoing messages, whereas in the system folders they are strictly separated.
And the Solution?
In short: Combine those four system folders into one which works like a custom folder. And display messages which belong together as threads.
In detail: I’ve posted my illustrated suggestions at the Thunderbird Wiki: Major Usability Redesign of Folders & Threads (in 4 Steps)
This Idea Was Inspired by
Cooper Alan (1999): The Inmates Are Running the Asylum — Why High-Tech Products Drive Us Crazy and How to Restore the Sanity. ISBN 0-672-31649-8How Email Programs Fail
[…]. Email vendors […] 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. 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. They act as though threads either don't exist or are an insignificant attribute of only a few emails.
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.
Footnote
[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.
