tecznotes

Michal Migurski's notebook, listening post, and soapbox. Subscribe to this blog. Check out the rest of my site as well.

Sep 2, 2004 2:09pm

regarding meta mail

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.

October 2017
Su M Tu W Th F Sa
    

Recent Entries

  1. planscore: a project to score gerrymandered district plans
  2. blog all dog-eared pages: human transit
  3. the levity of serverlessness
  4. three open data projects: openstreetmap, openaddresses, and who’s on first
  5. building up redistricting data for North Carolina
  6. district plans by the hundredweight
  7. baby steps towards measuring the efficiency gap
  8. things I’ve recently learned about legislative redistricting
  9. oh no
  10. landsat satellite imagery is easy to use
  11. openstreetmap: robots, crisis, and craft mappers
  12. quoted in the news
  13. dockering address data
  14. blog all dog-eared pages: the best and the brightest
  15. five-minute geocoder for openaddresses
  16. notes on debian packaging for ubuntu
  17. guyana trip report
  18. openaddresses population comparison
  19. blog all oft-played tracks VII
  20. week 1,984: back to the map

Archives