I’m going to start with the assumption that the developer is agenda-free and doesn’t feel a need to entice the user into the Internet data cloud. E-mails sitting on a server in another state, accessed with a Web interface and browser, may be okay for the enterprise, but generally not for individuals who want instant access, privacy and control. So the discussion here is constrained to a Macintosh application that uses POP or IMAP, in either a personal, work group or small business environment.
Understanding How People Use E-mail
Before one can design a solution, with a vision, one has to understand the basic problems with modern e-mail. Nemo, in his comments on Wednesday to my HD column, pointed out the “Conventionality Trap,” which is a great observation. Reader Bosco also correctly pointed to the “Hierarchical Filing Trap.” I’ll add another. The “Overload Trap.” The original design of e-mail programs, back in dial-up days, with an inbox and named mail folders was never envisioned to handle the volume of e-mail we encounter today.
The first thing everyone complains about, driven by the factors above and more, is the overloaded inbox. The inbox is used as a dumping ground because there are valid reasons for retaining an e-mail, but mechanisms to handle the retention are missing. For example, people will typically keep an e-mail in the inbox because it:
- has an interesting or valuable attachment.
- has a tidbit of technical knowledge
- contains valuable contact information
- schedules a meeting
- creates a task assigned by someone else
- asks a question that must be researched
- is too difficult or time consuming to file it in a named mailbox. By difficult, I mean UI nuances such as dragging accurately, remembering keyboard shortcuts, etc.
Then they hope they’ll be able to find it with a search. There are probably more reasons likes the ones above, but these are a good starting point. Once we understand why people retain an e-mail, we can start to deal with the problem. However, before I lay that out, I need to back up. Forgive the digression.
E-mail App Structure and Modules
Most e-mail programs provide a Filtering service, but filters automatically exclude or file a message. If filed, it can be forgotten. Two more modules are needed:
A Handler. An e-mail Handler is designed to allow user-level interaction instead of an automated action. It assists the user with handling a message due to the retention reasons listed above. Filters can never provide this kind of user interaction, so the end result is a message that gets through the filter, but is left in the inbox lacking any further assistance.
A Smart Viewer. Most if not all e-mail programs display every message the same way based on global preferences. But different kinds of e-mails need different viewing options. For example, if a distant friend sends a joke to 23 recipients, it’s okay for the viewer’s To: field to say: Tom, Larry, Jane and 20 more…. But if the sender is a manager or team leader, you probably want to see all the recipients without further ado. Another example is headers. If the message is suspected of being a phishing scam, you probably want to see the full e-mail header. If it’s from your mom, you don’t. A smart Viewer should handle all that.
Because all senders, if they get through the Filter, have the same status in modern e-mail programs, problems arise. There needs to be additional metadata for key senders such as boss, wife, kids, colleagues, etc.
A Logical Sequence of Modules
Now we can go back and look at a typical message. It wasn’t spam. That got blocked in the filter with, say, Spam Sieve. It was addressed to you personally, so it’s a candidate for the inbox. Next, the Handler comes up — something to be envisioned and designed — and interactively helps the user deal with the message. Here is where the user can assign keywords, redirect the message to storage, use data detectors to create an address book entry, create a task in a complementary ToDo manager like Things, or interact with a superior calendar program like BusyCal.
Handlers should be friendly and patient. If the user doesn’t want to handle the message, it can be marked as unhandled. Later, the e-mail program, learning from the user’s habits, can generate a popup and ask again if the message can be handled. User preferences can dictate when these reminders are allowed to pop up. The inbox remains sparse, if not empty.
The Handler and the Viewer should work hand in hand to provide the user with all the information needed to make a decision about the message and how to file it. For example, if the Viewer finds the sender in the Address Book, a section of the Address Book with all known information can be put in a corner of the viewer. (In case you want to call them.) Not everyone’s signature is complete. Also, the recipient should be able to drag-select over a region of the e-mail and store that information in a scrapbook. Many of the features of modern scrapbook programs are missing from e-mail apps.
In the end, the goal is to deal with the reasons why people default to leaving an e-mail in the inbox and create good handling procedures so that information, tasks, meetings, and so on are integrated into corresponding apps like calendars, ToDos, information archives, iPhoto, scrapbooks, and so on. Apple’s mail.app has some but not all of this, and it’s clunky to use.
I should also point out that Apple’s mail.app has a great contextual menu (right click) for selected text. It will even read portions of the e-mail out loud or do a Spotlight or Google search on the selected text. It’s a great start.
Summary
In this first part, I’ve defined what I believe would be a valuable feature for a next generation e-mail app. I have others in mind. In the meantime, please add your comments and suggestions in the comments below. As a group, perhaps we can make a diference.