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 6: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.

December 2018
Su M Tu W Th F Sa
      
     

Recent Entries

  1. How It’s Made: A PlanScore Predictive Model for Partisan Elections
  2. Micromobility Data Policies: A Survey of City Needs
  3. Open Precinct Data
  4. Scoring Pennsylvania
  5. Coming To A Street Near You: Help Remix Create a New Tool for Street Designers
  6. planscore: a project to score gerrymandered district plans
  7. blog all dog-eared pages: human transit
  8. the levity of serverlessness
  9. three open data projects: openstreetmap, openaddresses, and who’s on first
  10. building up redistricting data for North Carolina
  11. district plans by the hundredweight
  12. baby steps towards measuring the efficiency gap
  13. things I’ve recently learned about legislative redistricting
  14. oh no
  15. landsat satellite imagery is easy to use
  16. openstreetmap: robots, crisis, and craft mappers
  17. quoted in the news
  18. dockering address data
  19. blog all dog-eared pages: the best and the brightest
  20. five-minute geocoder for openaddresses

Archives