Email is older than the web, and it’s way past due for an improvement. I blogged in January about Email’s lack of support for JavaScript and this is related. It was a about a product idea that went nowhere. I proposed it to ThoughtWorks Studios, but failed to fill in the right paperwork and it didn’t go forward. Lesson: Read all your emails - folks!

Poor Person’s Google Wave

Synopsis

A channel for corporate communication to employees that only has up to date information, and uses email apps (mobile and desktop) to communicate that. More high tech, and less obtrusive than “Amber Alerts”. There’s also non-corporate usage too, but Enterprise usage is what you’d sell I think (Atlassian-style).

I very much liked the idea of GoogleWave by the way. This is a microcosm of that (just the “pervasive inbox” aspect) and reusing standard technologies. ThoughtWorks got our own Wave capability while it was in alpha status, and it was fun to play with it while it lasted.

Slightly More Info, and a little more technical

You would have a additional IMAP account for mobile device users (primarily) and desktop users (secondarily) that has emails that are updated/deleted in-situ in the inbox. That would happen regardless of whether they’ve been read or not. Actionable emails, with HTML payloads is one category, but informational ones too. The account doesn’t have outgoing or incoming email capability as such - it is invisible to the outside world. This is a programmable IMAP system, where authorized interoperating systems post updates, remove emails etc.

Of course the IMAP spec allows for items to be updated as it is. You can go as far as to test that with some clients (including Thunderbird with plugins). Just about all clients are perfectly happy to note that simple read vs unread state can flip back and forth. I presume too that clients are not far from being able to track bigger content changes to a previously received email. In time the JavaScript capability will be added to Email, and this capability will become even better.

For the stock Email app on the iPhone you’d have you regular Gmail / Yahoo / Hotmail accounts, and an additional one for this channel (Channel was the product’s code name). If you set it up, you’ve be able to see all email in one view as you’d expect via All Inboxes

Audience

First Round - corporate licensees - install inside the firewall. Second Round - Personal & cloudy, with readily available integrations.

Two Examples

Timesheet notifications.

Refer to the it’s time for email apps to support JavaScript article - scroll halfway down to “back to the proposal”. The email has buttons for interactivity, as mentioned in that article. But the email will also disappear from the inbox if the timesheet application reports that it’s been done.

Build-breakage news

Refer my aaw platform is awesome article (bottom of page - waves pervasive inbox):

“Since you last checked, The Foobar 3.x trunk build broke 17 times, but is now GREEN”

The item gets updated frequently of course, and is mostly informational. It could have a mute capability, like GroupMe and Gmail do.

Technologies

Hedwig Email looks like a pretty good starting point. If it does not have all the plugin points needed, you’d create some more. You’d definitely need a bunch of new scripty / restful / web-interface things for interop, a dashboard, and control. You’d also need a trust/sandbox model for things doing interop with the inbox over those new APIs (instead of an improved SMTP - see below).

At some level it feels like we’d need to keep and make available a history of what happened. Not only for regulatory reasons, but for the end user to be able to navigate too. Gmail’s roll-up of messages in the same thread is very useful, and it tries to pick the most pertinent info for the short rendition of the email in the inbox. Something deeper than that, perhaps. You’d ordinarily see the most recent version, but be able to click to see prior versions.

Maybe to some level SMTP needs to be improved, and force changes on clients such that some things even become ordinary for fire and forget email. “Your flight is going to be late” emails could be replaced by “your flight has been cancelled” ones. That’s not just matching on subject line, it is correlated to a senders message ID, and replacing in the inbox rather than supplementing or correlating, as happens now.

Conclusion

As I hint, I’ve tested the rewriting of email, and observed how it displays in iOS and Gmail, but we might find that delete & and rewrite is the better way forward.

We want to see JavaScript turned on in email packages. I feel that is inevitable, and it’d be nice to have a product that can immediately take advantage when that happens.

Colleague Andy Yates saw a few other platforms/portals/apps that could benefit from better sync between the main web or mobile fat-client interface and, and the weak aspect - email. He thought:

• Jive - which TW uses as a corporate wiki,
• Slack (IM tool de jour) could benefit.
• Zendesk - a trouble ticket system we use.

I guess there are hundreds of other pre-existing tools that could benefit. That someone else picked up the ticket can be useful if emails were superseded.

Google’s Inbox

I’ve not played with it myself, but I will do at some point I guess. I’ve read the reviews and it sounds like it is only a start right now. Hence my posting, while I’m still talking about things that have not been done yet.