First: stop thinking about this from a technical perspective. The problem and solution are not about how we build new protocols. That's just implementation, and as fun as it is to talk about that, nobody cares about your implementation. It only matters that it works and makes people's lives a little less painful. We need a solution at the level that the user interacts.
Email is Still Important
So, there are tons of posts out there talking about email is broken, and one of them has finally prompted me to write about it. If you're friends with me or you've interviewed me or I've interviewed you, you've probably heard me rant about this at some point. I haven't done anything about it yet mainly because of one crucial fact:
Whatever the solution is still has to work with email, and the email protocol sucks.
Seriously. Have you ever read any of the many specs involved? (Start with RFC 5321 and RFC 5321, then read RFC 6531, and then you have to deal with POP and IMAP...) It's a giant pain. So if I was going to improve email, I would start by digging through the Mozilla Thunderbird source code because Thunderbird is a great client and the hard parts have already been written for you. But it's a lot less fun to grok a program that huge that someone else wrote than it is to write something from scratch yourself.
This is fundamentally why Google Wave failed. Wave was a great idea that could have revolutionized email, but it didn't work with email. If you build something that replaces email, you still need to be able to send your grandmother a message with it. The reason email matters is because everyone uses it, and no one wants to use multiple programs for their different messaging needs. It's why intranets don't get used (unless, maybe, they have email digests or notifications). It's why your return-visitor rate is so low on the new website you're building. It's not because people don't like it or because it's not useful -- it's because they already use email and everyone already has email and it's just too much effort to use something else too.
There's another issue that has held me back, which is that support for proper HTML email is notoriously horrible in prominent email clients (*cough* Gmail *cough*). Like, we're talking worse than IE6. Worse than IE5 even. Only inline CSS is allowed? What? Anyway, there are workarounds.
What's Wrong with Email
We all know what sucks about email: we all have way too much of it, and there's no way to tell what's important and what's not, or what requires action and what doesn't, without reading every single email in your inbox. There's also a secondary problem, which is etiquette -- it's hard to express yourself clearly and politely in text without forcing your recipient to read paragraphs of prose or be unintentionally put off by your brevity.
How to Fix It
It's simple: build new features around email. It's possible to build a lot of things in an email client that only matter for the user of that client. It's also possible to build a lot of things in an email client that only work with other people using the same client, but still degrade gracefully for others. And it's also possible to build an enterprise email server that intelligently processes the internal email network. Here are some ideas:
- A lot of things Google Wave did would still work in this context. Clients that accept HTML mail could allow limited collaborative editing if the actual email was stored on a remote server, and text-only clients would just get a static copy. Videos could be displayed inline.
- Make prioritization and categorization of messages obvious and automatic. This is obviously a big deal and one reason Gmail is so popular, but it can be done a lot better. Here's a mockup I made last year that uses size and color to differentiate priority and takes a hint from the design of activity streams.
- Automatically extract tasks from emails and put them into calendars and to-do lists. Mark emails that don't need a response so they can be read without interruption.
- Add a "request protocol" that would let people send tasks directly instead of hiding them in prose. Done correctly, this could turn email into a project management system.
- An enterprise solution could allow integration with other company services, like posting documents to the intranet. This obviously depends on how the intranet is set up but there are things the email server could do to make this easier and avoid having to invent new markup syntaxes like most current solutions do.
- Automatically collect and summarize related messages.
- Manage company signatures like my friends at Airtime for Email are doing.
- An enterprise email server could determine an organizational knowledge graph and suggest other people in the organization with knowledge useful to your current project.
- Detect and manage stock responses, missing subjects and attachments, and unusual trends like a forgotten weekly meeting.
- Automatically remind you if you haven't responded to an important email after a significant amount of time.
- Build in serious encryption and security measures.
A viable product could be built around even just a few of these ideas; what really matters is the layer of abstraction between what works for all your contacts ("old email") and what works for people using your new technology ("new email") as well as the fact that users don't have to care about the difference.
Who to Target
You may have guessed by now who I think would be most interested in paying for a product like this: enterprises. Companies stand to gain the most from increased worker productivity, which could come from both better efficiency in consuming email as well as efficiency gains from richer messaging interactions. They're also more open to paying significant money for solutions like this. Plus, if you control the server as well as the client, you can add value by gaining insight into the whole interaction network instead of just the client's view. (Or, if you store every email from every client in the cloud, you have that data for an even larger network, and you save yourself some support requests.) The downside is that downtime is very expensive.
If you target consumers, you'll have a harder time getting away selling the client. Except for individuals who pay for Outlook, many people expect email to be free. You can probably follow Gmail's example and ask people to pay for storage or some other premium tier, as long as it's something you only realize you need to pay for after you're already hooked.
What are we waiting for?
The biggest reason in my mind that no one has done this yet is that it's an ugly problem. Although everyone wants a solution, no one wants to spend the un-fun time writing it. We're all busy reading our email.
But we can get there with baby steps. We can standardize ways to add functionality on top of email. We can improve HTML support in existing clients. We can encourage human standards that make email easier to consume.
That said, if I don't get around to writing this soon, I sure hope someone else does.