HN Explorer

Ask PG/HN : Replacing Email - What problems/solution comes to your mind?

49 points by anujkk ↗ HN
One of Paul Graham's frighteningly ambitious startup ideas (http://www.paulgraham.com/ambitious.html) is "Replacing Email". He visualizes his inbox as a disastrously bad todo list and email as the way things get into it. He shared his thoughts on what may be a better solution that can eventually replace email. Here are some points from that :

1. Email has to be replaced with a new protocol. This new protocol should be a todo list protocol, not a messaging protocol.

2. The new protocol should give more power to the recipient than email like

a)more restrictions on what someone can put on my todo list.

b)Information about what action I need to take on a to-do list item. Like, do I need to read something or take any further action on it like replying, forwarding, viewing attachment, paying attached bill, watching video etc. ?

c)How important it is? There obviously has to be some mechanism to prevent people from saying everything is important.

d)When does it have to be done? Is it urgent? Do I need to do it before a given time?

----------------------------

I would like to ask some questions about it from both PG and HN community :

1. In an email there are only few actions one is supposed to take, like "Read", "Read & Reply", "Read & Forward", "View attachments". What other actions you think that should be incorporated in new to-do list based system?If not all, what are the important ones for you?

2. How would you like to prioritize to-do items by importance? What are the rules? Like, giving importance to to-do items from specific "circle" of peoples you know - Colleagues, family, etc.? or by type/content of to-do item? or anything else?

3. What kind of things one can put on your to-do list? What kind of things one shouldn't be allowed to put in your to-do list?

4. Do we really need a new protocol? Can't it be done by making a distributed client/server system where anyone can setup an open source to-do list server(if they need to own and control their information for privacy reasons) and clients can communicate through HTTP protocol (REST API)?

5. Is there any YC company or other startup that is working on this idea?

Please share your thoughts.

66 comments

[ 2.8 ms ] story [ 120 ms ] thread
pknerd
Umm make it more similar to current postal system?
nicholassmith
The problem is, if you want to replace email it needs to play nice with email. You're not going to prise that from businesses unless it's out of their cold, dead hands.

A distributed client/server system would probably work, and you could go via REST, but if you're wrangling data along those forms as well as trying to fluidly integrate email into the experience (as it's not going anywhere), it might be easier to spec out a data format/protocol from scratch, you could even base it off REST if that floats your boat.

[deleted]
(comment deleted)
anujkk
I don't think any such system can work in isolation. We would need to integrate it with existing email system and SMS and may be also HN/Twitter/G+/etc if we consider reading all these as a to-do item.

One solution that comes to mind is to let users integrate their existing email accounts by allowing them to periodically fetch email through POP and converting it into to-do items. We can also add "Reply as email" and "Forward as email" actions to implement outgoing email functionality.

nicholassmith
But at that stage what you want is effectively a messaging client with heavy to-do functionality, rather than some transformative. Bolting the to-do functionality on is probably a lower-hanging fruit than a new protocol.

Ideally you'd need a protocol system that allows for multiple data formats to be specified through a plugin mechanism to cope with things like social networks and SMS on top of email, but then you're squarely in the territory of being at the whims and mercy of constantly ensuring the plugin works with the backend data APIs for the services (for social networks), and sticking to the letter of the RFC law for email.

It's a great idea, but as they say, going to need a bigger boat.

mike-cardwell
"1. Email has to be replaced with a new protocol. This new protocol should be a todo list protocol, not a messaging protocol."

We will always need a distributed, general messaging protocol. That's what email is. If you create a "todo list protocol", it wont replace email. It will either run on top of email, or along side it, but it wont replace it.

sigkill
Your comment nails the point. Email is to internet communication, as text files is to storing file data. It's the most basic form that's usable.

Sure, you could bolt on abstractions over it like doc/rtf etc. but at the most fundamental level you need some form of cross compatibility.

tvdw
1) Read, Write, Attach, Forward and Reply. Like it's right now. Maybe a "Mark as done" although the current mailbox system can easily do that by using folders and having an "Archive" folder (oh wait, we already have all that)

2) Labels and stars get me there. Oh wait, that's already in email as well. And remember the priority flag that lets others indicate how important they think it is?

3) Anything, as long as I can decide what's important and what's not.

4) Let's just stick with email. If it doesn't work for you as it is right now, stop using that webmail client you use and get a proper client. Email has always worked fine for me.

5) I sure hope not. I like email as it is.

Bottom line: I really don't want email to change. It's pretty good as it is right now, and mail clients such as Thunderbird offer all functionality any new system is possibly going to offer. If email doesn't work for you, you're doing it wrong.

batgaijin
I think google wave was really fucking close; if it had been backwards compatible (to a degree) it would have been a headshot.
leephillips
There were some email interop tools built on top of it, including an email notification system from Google. I think it was an excellent solution to several problems, but the default client was just too heavy and slow.
lunarscape
They also had a marketing problem. If they had simply called it "Gmail 2.0" or similar I think people may have used it more. I hope Apache Wave gets more traction. It's promising but I'm doubtful of its progress.
sandGorgon
Instead of thinking it as your list, turn it around and think of it as lists of people (or circles/bubbles if you please). The bubbles live in your "tank" of tasks. Your tank has different layers.

Each circle/bubble starts at the bottom but has a certain buoyancy - which guides its ascent to the top. For e.g., family bubble is very buoyant - so if you get a mail from your wife, it bubbles to the top really fast. In the time it takes to rise to the top, it can grow larger (more messages from your family) - which in turn increases its buoyancy.

The big difference is that you can change the buoyancy function at any time, causing the bubbles to start sinking/rising according to that change. Bubbles burst after some time - which means they get automatically archived or some sort of autoresponder sends an apology-for-delay email

You can play with different visual dimensions as well, like stale bubbles floating to the left.

mootothemax
Rather than trying to replace the entire system, try thinking about the individual problems.

For instance, Dropbox have replaced a big chunk of where people used to email files to one another. I've seen this both inside companies and when operating as an independent consultant. In fact, I've had a surprising range of otherwise non-technical people ask me whether I have it installed.

eterps
Exactly, the problem with e-mail is that it is not RESTful. Nothing is hyperlinked by default. Sending a huge binary to a group of 100 people results in 100 send messages including the huge binary, even though maybe 50 people actually did something with the binary attachment. But the same problem is sending a mail to a large group of users. For example if Amazon sends an e-mail to its user the complete content is transmitted N times. If with a RESTful architecture they only had to transmit the URL to that message with a subject. Users that are interested would open the message.
freehunter
To rephrase how I understand your comment, an email sitting in your inbox would just be a link to a glorified webpage hosted on Amazon's servers, where everyone can click through to that.

That's a pretty interesting idea. Emails from, for example, Amazon are pretty much just HTML files being sent to each user already. Obviously you would be able to customize the links sent as emails so each user can see the information they want being pulled from the database so it looks functionally like an email right now. Seems like it would be a nice bandwidth-saving protocol. It would also get around the issue of email storage and file attachment limits. It would offload the cost of receiving a message away from Google or the user and shift that burden back to the sender. Someone could easily tell how effective their newsletter is because it would count as a page view. The page could even be opened "within" Gmail as an iframe (or whatever people are using these days).

eperoumal
I don't see how a todo list can match the informational nature of an email. For example I've subscribed to some mailing list like misc from OpenBSD, how can it fit in the system you are describing ?
Tichy
I don't really get the TODO list thing (even though I think PG mentioned it himself). Is that because people tend to mail their TODOs to themselves? Or because most email translates to TODOs?

I know that I certainly don't want a system that allows people to push TODOs at me.

InclinedPlane
Every email is a todo. Period. Full stop.

This is true regardless of your work or workflow. Consider that at the very least most emails tend to be an implicit request for a reply. In most cases that reply requires at the very least remembering some bit of information (in the best case scenario something that is trivially easy to recall). And even more fundamental than that, each email message is an implicit command to digest the information contained in it. But beyond that, it's quite typical for work to be tracked or requested through email, for some jobs it's by far the normal way that the vast majority of work is organized.

Tichy
Most emails are spam, actually. Some legitimate, but the majority doesn't warrant a reply (like all the "marvel at the new features of our startup" mails). Of course the mix varies from person to person. And they are TODOs in the sense that you feel like you should delete them, or archive them, or whatnot.

I think it would be better to make most of them go away automatically, though. Perhaps things like "automatically save attachments from x into project folder z" would help (already doable? I don't use filters much).

Maybe it really would be better to make emails a universal transport layer and integrate it better with other stuff. People send you a TODO -> goes into TODO list. People send you an image -> goes into photo library. And so on... Of course I always hated the idea of Outlook of allowing other people to mess with my calendar, so I don't know...

InclinedPlane
The easiest thing to look at is all the pain that people have with email as it exists today. There is the core of email, but then it is festooned with many additions, extensions, associates, and helpers. All of those things are there for a reason, because they solve a real problem with email. But, of course, those things don't have the luxury of rebuilding the whole system from the ground up, and doing so could lead to a design that doesn't have the pain points and weaknesses that need to be mended by additions. Consider a few common aspects: at a big company the MO is typically for individuals to join a large number of distribution groups and then also set up a lot of filters to move the mail they get for those groups into different folders because they have different levels of actionability (if any). Similarly, automated emails tend to require special filtering rules to make sure they don't drown out the S/N. Add to that the common difficulty of personally or publicly archiving email, because so often it tends to be used as an information storage system for key bits of data (contacts, decisions, technical details).

Personally I think the "todo list" model is good but lacking. I think ultimately what you want is something that would look to us like a mashup of issue tracking, messaging, wiki, and maybe even twitter from a certain perspective. I think switching from "private default" to "public default" for messaging is the biggest toggle, with the second one being pull vs. push (or search vs. signup).

thalur
The thing that jumps out at me is your first question: the majority of the actions I get from e-mail come in the text of the email and are external to the mail client (implement this feature, fix this bug) rather than part of it (reply with an answer, accept meeting request).

I think the reason why email works for this is that somehow email "comes to me" whereas everything else I have to consciously "go to it" to check it. I recognise that some of this is habit, some of it is how the email client is integrated into the computer (outlook at work, mail on my iphone) so that it presents new stuff to me directly, and some of it is that it presents a single place to check rather than having to hit refresh on a bunch of webpages to see if anything has changed on each.

seunghomattyang
An email client that lets me edit the title and body of the mails in my inbox would be a good start. I use email as a to-do list and oftentimes, 90% of the text in the email is not pertinent to that purpose (greetings, signatures, "polite" introductions, etc). Just being able to edit out unnecessary text would be really convenient. The changes would sync with across devices that have this specific mail client and you can restore the original text with just a click.

TL;DR: Mail client that lets you edit other people's emails in the inbox so that you can edit out things that don't fit the context of your mail usage.

morsch
Maybe PG conceptualizes his email inbox as a bad distributed todo list, but I'm sure lots of people don't. I don't. My work processes are in an actual distributed todo list of sorts.

That said, clearly email is being replaced by other messaging techniques. There was an infamous Slashdot story in 2004 (christ I'm getting old) In Korea, Email is Only For Old People[0]. Back then, it was blogs, IMs and SMS, these days it's, well, still blogs and IMs and SMS but also Twitter and Facebook messages. Particularly Facebook messages.

Which is reason enough to think about replacing email -- with something that is as attractive to people as these techniques, but not proprietary, but rather at least as cross-platform, distributed and reliable as email.

[0] http://slashdot.org/story/04/11/30/0034259/in-korea-email-is...

mgkimsal
IIRC, the followup story proclaimed that "In Soviet Russia, email only reads old Korean people". But I might have misremembered that.
ed209
It's not about a to-do list.

Email is a generic container. It can contain to-do's, sure. But it might also be a letter from a friend, an invitation to a wedding, a mailer about discounted products.

The way to improve this is to redirect emails to the relevant place. To-do's to my to-do app, invitations to my calendar, mailers to my Flipboard like app that sucks in all offers and puts them in one place.

The point is none of this stuff should ever touch my inbox. Additionally, if I don't have a "offers mailer app like flipboard" I'll never see those offers.

This can't be done at the client level. But it could play nice with existing email. As the message comes in, you either have an app (registered on the server) that says it can deal with that email content or the message gets bounced. It's kind of harsh, but I suspect most people's inboxes are taking way too much time out of their day - more that it should.

Then on the client side, you'd have a collection of apps that would be designed specifically to deal with those message types.

drharris
This, to me, is the winner, minus the bouncing. Email servers or clients can append headers based on what content is in the mail, and that information can be used to provide context sensitive app links. I can imagine a big button next to an email that says "Add to Calendar" or "Send to Evernote" or "View Map/Directions". I think Gmail does a good bit of this, so if they can provide hooks for more external services to capture, it would be a huge win.
ed209
the bounce is a bit harsh I'll admit. but the point I wanted to make was that if I don't want that type of message then return the message to sender.

i.e. if I don't have a to-do list app registered, don't send me a to-do.

drharris
Ah, that makes more sense. I don't make appointments over email, so bounce an invitation and they can see me in person. I've always liked the idea of email as a non-guaranteed protocol.
lmm
1. I think you're misunderstanding; actions are a more general concept. Most emails I get fall into one of several boxes: "confirmation, no action required"; "event you might like to attend"; "request for email reply"; "request to do some thing in the real world"; "notification that something you were waiting for has happened". I'd like it to be possible for an incoming email to be marked as one of these (and the client can use it to determine e.g. whether my phone beeps). I'd like closer integration with my calendar; currently if an event email has been formatted right (which most of them aren't) I can "add" it to my calendar, but that's a one-way, fire-and-forget process.

2. Eh. I can handle my priorities. Maybe some very simple high/medium/low priority based solely on sender, but I don't want anything complex.

3. Anything can go on there. If I don't want to do it I can handle that myself.

4. Eew, my buzzword bingo went off. A REST API is still a new protocol. Anyway, the point of making this a new protocol and not email is that if I just add tags to email, 99% of incoming emails won't have these tags and they'll become useless. The only way to make senders adopt the new format is if they gain a benefit by doing so; with a separate protocol, maybe I'm willing to have my phone interrupt me for (some) new-protocol messages, but not for email. That will give people an incentive to use the new system.

leftnode
The two biggest issues for me have to deal with communicating with groups of people.

First, I hate being involved with an email conversation between several people that lasts for days and you end up with a 100 email long chain. It's difficult to wade through the crap, everyone has their 10 line signature and the useless privacy warning for a 1 line email. It's annoying and very inefficient.

The other annoyance is not being able to unsubscribe yourself from threads that no longer are of interest to you.

This happened recently at work. I was communicating with our QA manager and our clients QA manager. I had taken care of my part, and they continued the conversation through email yet I still received every email because they would just reply all. Eventually I had to send an email and say "next time you send an email, please remove my name from the list unless I actually need to read the contents of the email."

To me, a simple solution to this is a threaded message board (even ones as simple as like vBulletin and the like from the early 2000's, obviously built with better technologies).

With a message board you have control over how much information you consume, but if someone really wants to send you something, they can send you a private message and ask you to join a conversation. You subscribe to threads of conversation, and then unsubscribe when they no longer interest you.

Find a way to do that in an email client and I'd easily pay $100 for that piece of software.

InclinedPlane
This was the problem with google wave. It tried to solve the distribution problem, but that's easy and solved. The real problem is the opposite, signal-to-noise and information overload.

Also, there is the general problem of keeping information up to date. If every new participant to a conversation has to follow all the convolutions of the original email thread (some of which may be missing because face-to-face meetings probably happened at one point) then that's a huge waste. Figure out how to create a system which naturally encourages people to sum up the current state of the discussion (perhaps with automated aids) and you'll be ahead of the game.

datr
I feel like google wave tried to tackle these problems as well.

Specifically, it was possible for people to join and leave a conversation much in the same way that facebook messaging threads work now.

While Wave did subscribe fairly heavily to the traditional message and reply model it also had support for wiki-style messages, so it was possible for a summary to be maintained in the top message of each thread. (The instant replay tool I always thought was very cool, too.)

And towards the end it did start to introduce some tools to encourage people to summarise information (although admittedly nothing revolutionary). I'm mainly thinking of its widgets for event organisation, date planning and voting which are always horrible to do via email.

I think Wave had a lot of problems and, it may be, that the problems it did solve it didn't solve well but I do think it at least tried and had a few good ideas.

rhomboss
Gmail solved (mostly?) these problems for me: you can mute conversations (archive & automatically mark new messages as read) from the dropdown menu on the inbox screen.
rshlo
email doesn't need any replacement. it's a fantastic messaging protocol. It's used by millions and every system supports it. Maybe in the far future it will disappear as other messaging protocol will rise, but we still use phones and snail mail, and there are very old. What need to be replaces is the bridge between email and todo protocol. The task management tools, even now, are not solving the problem of intelligent task management and creating more work than reducing it. You have to file, categorize, make priorities, or even type the tasks yourself. That's the reason people don't use them and use email instead as a task management tool - which it doesn't support.
prawn
One thing that is broken in most cases: email signatures. I can appreciate that they serve as a practical branding opportunity like a business card or letterhead, but no one needs to see their own in a chain of replies.

I recently converted from Outlook to Gmail and end up with email tails that consist of a stack of signatures. I'd rather easily insert a signature (easy shortcut in Outlook) in the first contact with a client than have to delete one that is automatically appended to a sequence of replies. I suppose my best bet is some tweak/add-on that allows quickly choosing a canned response?

Wish there was a concise signature format that combined fixed data pairs (Phone = 1234 5678, etc), branding chances, and a maximum size+. Then (as some mail clients or web apps do) show this info as a 'card' in a right sidebar, and stack those cards in the event that multiple people are in the conversation.

+ And automatic stripping of those "Keep it green, read on screen" messages. If someone's going to print an email, they'll print the email.

adyus
I think the solution to that is simple on the client side. Any text that repeats itself in two emails from the same person (including one's own) can be considered a signature and hidden. Gmail does a pretty good job of that.
prawn
Doesn't seem to do it for my signature - does it only happen in Conversation Mode or whatever it's called?
monsterix
Let me share my thoughts as we have been working on these ideas lately. To see our work please visit http://bubbleideas.com

At the outset, let me be straight and upfront to say that it is nearly impossible to kill or replace emails. The idea may be frighteningly ambitious, but from where things seem to be one cannot possibly replace email by creating yet another (so what if better) - mail service.

Current level of email, its provisions, functionality, simplicity and pervasiveness are enough to keep the user coming back in and keep him/her satisfied too. Probably the thinking of having an evolved protocol, that provides for more control on who can/cannot write is also not ambitious enough. At least not so much as the idea itself is.

What I mean to say is that the approach to execute a disruption of this level one has to think on a bit on radical lines. Answering 15 regular questions on a HN post may help but not let you get away from reality. Think deeper, perhaps.

Fifteen years ago emails nearly killed physical letters (yes they do exist even today) with its convenience, simplicity and for being completely free. At that time the need to be able to write to anyone with something as simple as a form hit at the bottom of one's hierarchy of needs.

Now this is not the case. The need to move to something higher or better is not at the bottom of my need-pyramid. I believe this is true for many users out there. One cannot just service, iterate and evolve from the existing to be able to disrupt/replace. That's what my thoughts are.

dgudkov
IMO the core problem is that we're trying to use asynchronous service with poorly linked messages (email) for conversation between people which is synchronous, strongly linked and subject-oriented by nature.
saulrh
Everybody uses email differently. Any one person proposing a "solution" to email or a new client design or workflow or whatever is going to be shouted down by the 90% of the population that doesn't do it the same way.

The best thing, then, might be to let everybody design their own email client. I'm imagining something that lets you drag around GUI widgets like "this email has a to-do item associated", "displays this email's author", or "mark this email as being high/medium/low priority". Provide a few layout tools, maybe a really simple domain-specific scripting language in case someone wants a widget that you didn't provide, and everybody's happy.

anujkk
I would rather try to make that 10% of the population happy than try to make everyone happy. I can't do that and I don't know anyone who can do that.

I'm sure if I can delight 10% of existing email users to a level where they are ready to pay me it is going to be big, very big.

vr000m
The big advantage of email is its federation and no need for end-to-end connectivity (Store and Forward paradigm). Today due to cloud computing this could be attempted as a monolithic service and the messages can be stored in the cloud until delivery (or even afterwards). So a new email protocol should take into account if it needs federation (distributed) or not and what would be the intended reach.
TimJRobinson
Very true, perhaps something along the lines of sublime text. So at it's core it's just a fast simple email client. Then have a really nice plugin system so people can create their own plugins really easily to customize it or add functionality as they like.

Of course non-geeks won't really understand installing plugins however others could create services (whitelabel versions) that have a bunch of plugins pre-installed so they work well out of the box.

[deleted]
(comment deleted)
nicholassmith
That sounds similar to the Steve Jobs Calculator Construction Set story (http://www.folklore.org/StoryView.py?project=Macintosh&s...).

For the 90% of people I imagine until something much better is forced upon them they'll be perfectly happy with what they have, be it Gmail or Outlook. For the people who want a better experience, I imagine a lot of them will have the technical ability to strike forth and do it.

Essentially what you want is a backend message server and then let people communicate with it however they fancy with a high level API they can plug into their widget toolkit of choice if you go down that route. If you're into C++/Qt there's already a solution that does that (http://labs.qt.nokia.com/2009/09/21/introducing-qmf-an-advan...).

Myrth
When I need to reach someone, I usually want them to respond as soon as possible. That's why I'm trying to find a way that I know they receive. Sometimes it is skype/gtalk (if i know that the person is at a desk with clients online), sometimes it's sms (if i know that they have their phone). And of course, voice call, if text doesn't cut it.

If I know their main communication agent is email and it's business hours, I will send an email.

My point is, you can make a perfect replacement for the email, from point of view of recipient, but people who are in control most of the time are the senders.

THEY will choose a way to contact you. If they see that FOR THEM it is more efficient to send a chat, SMS or email, they will do it.

Of course, you may try telling them: "That's it, I'm using only my new perfect todo tool", but I don't think it will hold for long.

I may definitely be totally wrong.