In the first article in this series, I looked at how a combination of filters, then handlers, then a smart viewer for each e-mail program would assist with the various tasks that can be associated with each e-mail. In this installment, synthesized in box viewers are examined.
When I think about named mailboxes, what I see is the easiest and quite possibly lamest solution to sorting and filing e-mail. That's because computers tend to be hierarchical, and programmers take the easiest route. But, really, should (and can we) have a named mailbox for every possible project? That just doesn't account for the volume of e-mail we receive these days over broadband. Soon, the proliferation of named mailboxes leads us to strain for simplification by creating hierarchies of named folders. All that does is create an artificial visual simplicity while burying important e-mails still farther.
Metadata is Our Friend
Just as Apple found it useful to modify its file System, HFS+ Journaled, to include metadata for Spotlight, it's far more useful to attach metadata to an e-mail. In Part I, I described how this would work. Messages that, for example, name you specifically get through the filtering process. Then a Handler assists with figuring out what task, if any, is associated with each message. Then, the message is stored in a database archive.
Those messages that, for example, end up creating a calendar entry are filed away in the database, never to disgrace the in box again. The reason we retain those kinds of messages is because there's no innate assistance by the program, so we trust our own ingenuity to go back and look for the message, likely in the in box. Bleccch.
Synthesize the In Box
However, it's also desirable to also define an overall view option. Thunderbird 3 does this with the "View:" popup. For example, it's easy to bring up a synthesized in box that contains "All messages received this week." Or, "All messages that contain the tern 'Psystar'." These views are customizable in many ways and essentially create a software controlled work around to the finite, static, named folders that we waste our time copying messages into. As a result, the in box is never a lazy list of messages we never got around to dealing with. Rather, it's always synthesized, recreated, by some user definable rule.
That brings up the idea of what metadata is associated with each message. That's where the Handler comes in. In some cases, the Handler can use predefined rules. For example, if the Subject line contains the string #admin, the Handler knows how to add that term to the catalog of tags. That's something familiar users can agree on without requiring standards adoption. Then, instead of a mailbox named Admin, I have a lot of messages tagged with the term admin, and I can create a synthesized inbox, ordered by time or sender, whose metadata includes the term 'admin'.
When I double click on a message of interest, the Smart Viewer shows a log of how the message was originally handled, whether an event was scheduled, the tags, the contact information of the person who sent it, and so on.
After awhile, more and more e-mails should be auto-tagged requiring only occasional manual intervention by the user to create new tags. A list of tags should be trivially easy to call up. One tag might also be, "unhandled," but any e-mail message can still be searched for by key word in the body or sender, date... all the usual ways.
The Apple mail.app tries to do this with Smart Folders, but one cannot have, so far as I know, a Smart Inbox. One might be able to funnel every message into a Smart Folder called INBOX, then work from there. But after the Smart Folder is defined, there's no Smart Viewing as in Thunderbird 3. In other words, one has to work hard to get it all set up. Instead, the philosophy above should be part of the design of the app itself.
An Example
So let's look at a hypothetical example. I have a filter set so that the only messages I need to handle are those addressed to [email protected]. The rest are dropped into the database. Next, the incoming message is analyzed by the Handler. I supply a tag (tech info, person of interest, useful attachment, etc.) if necessary, allow it to schedule an event or reminder, and the message also gets dropped into the database.
What if someone calls and says, "Did you get my message on Monday?" I may not remember, but I can always pull up one of the view options and display all the messages that arrived on Monday, even spam, and scan through them.
More Perspiration and Inspiration
The bottom line here is that e-mail developers have gotten lazy because there's no money to be made. Or so it seems. Accordingly, they place a lot of the burden on the user to manually organize information by creating folders, dragging and dropping, using keyboard shortcuts, searching the inbox and so on. Or, as a cop-out, they let various plug-ins that achieve, in a rather haphazard way, what they should have been coding for in the first place.
I think users would gladly pay for a next generation e-mail program that has no named folders, no static, but only a dynamically created in box, and which can work with the Mac without having to appeal to standards to be imposed on the rest of the industry. Surely, with a Mac capable of 50 gigaflops and a terabyte drive, we can write an app that serves us instead of making the user its slave.
If that happens, every other developer will be thinking how they were so asleep at the wheel.