Email is my prefered method of communication (besides in person). At the same time, I get a lot of it, so making it better via tooling is very important to me. A large proportion of the emails I (and many other people, I’m sure – especially those in the tech world) receive are generated automatically, from LinkedIn notifications to Jira updates to monitoring alerts.

Email is good at receiving information, but then acting on the information is encumbered by the need to link out to a browser. In fact, the whole process is ungainly: receive email -> link out to browser for a single action -> return to inbox to delete message and move on, often to the next message generated by the same web app. Fixing this is just a matter of allowing mail clients a means of handling actions without linking out. They already format HTML and CSS, it’s time to add javascript as well. Let me give you a couple of examples.

When I’m monitoring a MongoDB cluster with MMS I set up email alerts, such as one for replication lag; I am emailed if lag crosses a certain threshold (2 minutes) because in that case I want to know about it immediately. What I read that email, there are a few things I want: to see current status (that email could be old), take an an action (acknowledge, escalate), or get more information. Current status is key, as there is often lag between event and email receipt. A list of one-click actions in the email would save considerable time when dealing with a full inbox. More information options embedded in the email would also save from switching context.

Another example is jira. I often get dozens of jira threads in my inbox between email reading sessions. Its great to be able to use gmail keyboard shortcuts to go between these threads and perform all the message management tasks common to email, such as viewing and archiving. What would be much better is being able to use keyboard shortcuts to make comments, edit fields, and take any other jira specific actions directly while processing these messages. Also having different views based on the device I’m using (desktop, mobile) would be very convenient.

One solution I’ve been thinking about is email apps. Emails could contain another mime section (text/email-json-application) that was a json document describing a minimal application. One option is for it to contain a URL for a javascript app (versioned for caching), along with the data payload particular to the message. The javascript API the app used would have to be consistent across all mail UIs and a pretty trimmed down system. Since it’s another mime type, this system would be totally backwards compatible since you could still have text/plain or text/html.

Google is working on something in this space. Google is the only company sucessfully doing real innovation in email, which definitely makes me happy. That being said, they’re trying to implement a limited set of features, and they’re doing it embedded in the the text/html segment of a mail message, which I don’t like. Overall, I think their solution is too timid, and a bolder idea is needed to really make a noticeable difference.

So what would have to happen for this to be real:

• Someone crazy enough to take up writing a spec and api design
• Write chrome extension for gmail as an experiment
• Hook it up to some system that sends a lot of email

Anybody?