Meta-mail

In an item entitled personal message deflection, Phil Windley says he'd like to move his process-related communication out of email and into task-oriented software. Here's the glitch:

One problem with moving from a single general purpose tool like email to multiple special purpose tools is split focus. To understand what I mean, think about RSS. RSS has reduced the number of mailing lists I subscribe to and consequently reduced my email traffic. Perfect application, except that now I have to remember to fire up my feed reader in addition to my mail client. I generally treat it as lower priority and so I'm reluctant to get high-priority information delivered by RSS. What happens when there are a dozen special purpose tools managing my workflow instead of just a linear email list? [Phil Windley's Enterprise Computinging Weblog]

• One of our consultants (Srikanth) discovers that he cannot file a support incident with a vendor. Our service contract has lapsed, and he is stuck.
• Srikanth sends me (John) email, asking me to get the service contract renewed. He is stuck, so he marks the email as "urgent".
• My inbox is relatively empty, so I actually read the email (within an hour or so).
• I reply to Srikanth, and forward the email to my boss (Sam).
• Sam replies to me, and directs a request to the head of the group that "owns" our contract with the vendor (Amy).
• Amy sends email to the team member who works regularly with the vendor (Mary).
• Mary sends email to the vendor.
• The vendor replies to Mary with terms for renewal.
• Mary forwards the terms to Amy for purchase approval.
• Amy approves the purchase, and emails our purchasing department (to issue a purchase order).
• Our purchasing department issues the PO to the vendor.
• The vendor emails Mary the new support keys.
• Mary emails Amy, Sam, John, and Srikanth the new support keys.
• Srikanth uses the keys to file the support incident.

...

The point of this example is that a business process is being conducted via email. Each message is a step within our ad-hoc "renew a support contract" process. I am certainly not bragging about the details of our process, but it should seem pretty familiar (and pretty scary). Each email is distinct and unrelated to the others except for the likely inclusion of the email thread within the body of the message. There is no easy way to track the progress of the process (except to send follow-up emails), and it doesn't take much for the process to stall.

Dyson's solution is to identify messages as process steps by embedding meta-data within the email. Meta-data can add meaning to email, and this meaning can be used "to look for and manage processes, activities, transaction threads and the like by what often matters most: links between events and activities, timing, state of doneness or dueness, attributes that have to do with the state of interactions among objects and people." [John Reynolds]

Exactly! This was a central theme of my groupware book. We spend a lot of time, in email, enacting protocols that could be (to some degree) formalized. There's a delicate balance to be struck here, of course. Most business processes mediated by email have both formal aspects (you ask me to perform a task by a certain date) and informal aspects (we negotiate, and realize something else we hadn't thought of should take precedence). The conversational nature of email is its irreplaceable strength. That's why we keep on re-inventing email within special-purpose applications. And it's why I've long argued that our general-purpose email software has to be more programmable, and has to have robust support for extensible metadata. Here's the conclusion I came to back in 1998:

Messaging is at the center of all groupware activities. We need to be able to deeply customize our messaging environments. There are two ways this can happen:

Enrich the browser's user interface and local data store.

There's a reason we prefer our fat messaging clients. They're powerful information-management tools, and we need all the power we can get, because message traffic is our lifeblood. It's about time to extend HTML's tired old widget set, and if that happens, messaging widgets -- a multipane viewer, a tree control, a rich-text and forms-capable composer -- should top the list of desirable new HTML features. Of course, these things should be scriptable by way of a standard Document Object Model (DOM).

Better UI alone won't solve the problem, though. Browsers today are quite limited in their ability to store and manage local data. A cookie file is hardly the place to put megabytes of semistructured, searchable message data. Messaging clients use powerful -- and proprietary -- embedded database engines to manage local message stores. Should this machinery migrate into the browser? Perhaps so. Ideally the proprietary message stores would offer standard DOM bindings so that custom messaging applications built on top of them could be portable.

Componentize the messaging client.

Instead of moving all the rich functionality of the messaging client into the browser, why not bring the browser's programmability into the messaging client? There's almost no limit to what you can achieve with the right set of scriptable components. But in the Internet realm, the messaging client is conspicuously unable to work as a scriptable component. Notes and Exchange developers routinely create custom forms and message types that provide, right in the messaging environment, the flexibility that Internet developers can only achieve in web space.

As in the browser case, this solution should provide an API that insulates scripted applications from the proprietary message store. There are all sorts of groupware services and components that need to be built. If the messaging client becomes a platform for such services and components, it needs to be an open one so that development activities have the best chance of reaching critical mass.

I'd settle for either or both of these solutions. One way or another, I hope we'll end up with an Internet messaging platform that has the ultimate flexibility of the web programming model, plus all the features of the fat messaging clients. That's the platform on which we can build the next generation of Internet groupware. [Practical Internet Groupware: Epilogue]

Six years later, both strategies are in play. If the Alchemy idea finds its way into Gmail as I suspect it will, we'll finally get to see what webmail might really be capable of. And if Chandler pans out, we'll similarly get to see what a full-strength messaging client built for scripted extensibility can do. The question is what we make of these capabilities.

Phil's post concludes:

I think the answer to this problem lies in creating a task dashboard and having the various applications, including email, post control messages to the dashboard so that I have a single place to manage the various messages that are coming to me, albeit outside email. I'm envisioning something more flexible that a simple dashboard. I want a rule engine, easy graphics, templates, and so on so that I can customize it to the way I want to work.

Former URL: http://weblog.infoworld.com/udell/2004/09/02.html#a1067