tecznotes

Jon Udell writes today about Meta-mail:

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.

It's a response to Phil Windley's comments regarding meta-data in e-mail:

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.

Unfortunately, formalizing the kinds of desires and activities that are engaged in on a day-to-day basis is as difficult as the general problem of meta data. The features that currently exist in mail to handle this need (return receipts, urgency levels) are often misused, and in my experience unhelpful. Often, they are simply left unimplemented in many mail clients - the List-* headers are recognized by Pine, but not by Apple's Mail.app.

Fortunately, e-mail is an easily extensible communications medium.

I imagine that a potential approach to addressing this need would be to delegate a solution to the people who need it most - the IT and operations departments already tasked with formalizing process flows within a company. Many such formal processes take the form of simple expressions of desire, belief, and intent.How difficult could it be to augment mail headers with entries such as X-Desire-A-Meeting or X-Intend-To-Visit that could be customized to an organization's specific formal processes? Tie these to a DTD-like definition that specifies the syntax and potential range of expected responses to each message. Couple this with a few extensions to an open-source webmail client like Squirrelmail that implement a minimal interface to the message composition window and incorporate the inbox/outbox fusion of Gmail's conversation view, and you're on your way to a workable method. The key for me is that it should not be necessary to wait for a corporate software powerhouse such as Microsoft to develop a one-size-fits-all extension to Exchange or Outlook. Technologies like the world wide web or RSS have shown that one way to solve a communications technology problem is to use the tools at your disposal, and build a solution incrementally.