
Ask PG/HN : Replacing Email - What problems/solution comes to your mind? - anujkk
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 :<p>1. Email has to be replaced with a new protocol. This new protocol should be a todo list protocol, not a messaging protocol.<p>2. The new protocol should give more power to the recipient than email like<p>a)more restrictions on what someone can put on my todo list.<p>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. ?<p>c)How important it is? There obviously has to be some mechanism to prevent people from saying everything is important.<p>d)When does it have to be done? Is it urgent? Do I need to do it before a given time?<p>----------------------------<p>I would like to ask some questions about it from both PG and HN community :<p>1. In an email there are only few actions one is supposed to take, like "Read", "Read &#38; Reply", "Read &#38; 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?<p>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?<p>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?<p>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)?<p>5. Is there any YC company or other startup that is working on this idea?<p>Please share your thoughts.
======
harel
I just don't get this constant fascination of being the one who changes email.
This constant race to invent a solution to a problem that doesn't exist. Email
is not the problem here. Its a textual piece which is parsed by email servers
and your email client to deliver 'stuff' to you. That stuff can be anything in
the world. This is what makes email such a success that not PG nor an entire
pantheon of gods will manage to 'change' or 'reinvent'. Its the simple
technologies that end up being the most genius ones. And every two days
someone wants to come in and make simple into complicated because they have
this idea that the world will actually prefer complicated. Its not a 'todo
list' Mr. Graham. Its a generic piece of message or content I'm being sent or
sending. Some of it are tasks to perform. Some of it is my nan asking how her
grandchildren are, and some of it is Mr mamboto of Nigeria who wants to give
me 35 million dollars - Win!

There is no problem with email. You don't want to change email. This is not
the problem you're looking for. What you should be looking, perhaps, is a
smarter email client which can represent the contents of various email's
differently based on the context of the message. Some messages are todo lists,
some are letters from nan, some are offers of a better life from Mr. Mamboto.

~~~
simantel
While I would tend agree with you that we don't need to change email, your
examples actually do fit quite nicely into the "email as to-do list" idea:

An email from Nan would be a "read and reply" task. The email from Mr.
Mamboto, assuming it's not caught by my spam filter, also requires me to take
action.

~~~
matthewowen
I disagree with this quite strongly. If you think that 'an email from Nan' is
a 'read and reply' task, then you can turn everything you ever do into a to-do
list. Buying a steak is a to-do item because you have to cook it. Discussing
what someone's reading at the moment is a to-do item because you have to
decide whether to buy the book they suggested. Etc, etc. Almost everything we
do either completes a task or creates a new one, if you want to see it that
way.

For extremely busy people, everything becomes a to-do list. And this is why
I'm somewhat unconvinced by PG's notions of email as to-do list. It probably
is if you're a busy and successful person who gets a lot of business
information and requests via email.

To my mind, the reason email seems that way more than other communications is
largely because email clients give you pretty good ways of turning those
communications directly into to-do items (unlike, say, the telephone, where
you have to explicitly consider and organise the tasks that come from those
communications).

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

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

------
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).

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

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

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

------
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...](http://slashdot.org/story/04/11/30/0034259/in-korea-email-is-only-for-
old-people)

~~~
mgkimsal
IIRC, the followup story proclaimed that "In Soviet Russia, email only reads
old Korean people". But I might have misremembered that.

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

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

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

~~~
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.

------
jimrandomh
Think of it as a classification problem. Every message falls into one of four
levels:

1\. Should read immediately (generates an interruption)

2\. Must read, but can wait (goes in a queue that I look at regularly, and
must be marked read)

3\. Maybe worth reading, but okay to miss (goes in a pool that I look at
sometimes, but disappears if ignored. This pool should be bottomless.)

4\. Should not read (uninteresting stuff, spam, and duplicates)

We have many ad-hoc systems for performing this classification, and email is
only one of them; we use the medium itself as a proxy for parts of this
classification.

Gmail's Priority Inbox is meant to distinguish level 1 from 2, and its spam
filter to distinguish level 2 from 4, but it breaks down when level 3 messages
(such as mailing lists) get into your inbox. RSS is for level 2 only, and can
neither escalate to 1 nor filter to 3 and 4. Forums are for level 3 only. News
aggregators like HN distinguish between levels 3 and 4, but they suck at
escalating to levels 1 and 2, and their ad-hoc nature means that they have
pretty serious duplication problems; an awesome post is still a level 4
message if you've already seen it.

If you want to replace email for me, you need to go broader; let me pull
everything into the same system, then get the classification right.

------
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?

------
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).

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

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

------
prawn
Are there any mail clients that handle CCed mail quite differently to direct
mail in the inbox?

BCC to me, in most contexts, is "You can eavesdrop on this if you want." CC is
sometimes "Just showing you that I am on top of this" and sometimes "I'm
mostly dealing with Rollo, but there could be a question/task for you in here
too."

In inbox terms, something very roughly like this: if I'm CCed on a message
from employee Bob to client Rollo, it could say "Bob emailed Rollo about 'The
contact form bug' and included you." And maybe alert me if my
name/alias/nickname (hard to catch them all) is mentioned in the body.

If BCCed, maybe "Bob emailed Rollo about 'The contact form bug'; you can read
it if you want."

In each case, neither should really be given the importance of an email sent
directly to you.

------
adyus
I think the current email protocol should not be changed, for maximum
backwards compatibility. The solution should be a web (or native, why not)
client that does all those things based on the email content.

The difference would be giving feedback to the sender ("your email has been
marked as important" or "your email has been converted to a task" etc.), with
obvious incentives to convert to said email client. Thus, if both recipient
and sender use the solution, this feedback happens in-app, without emails
being sent back and forth.

There's a lot of room for creativity when designing a client. I liked someone
else's idea of integrating with the various web apps such as todo lists,
calendars etc. to keep from reinventing the wheel.

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

~~~
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.

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

------
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 ?

------
eterps
Relevant? →
[http://web.archive.org/web/20110607224446/http://www.prescod...](http://web.archive.org/web/20110607224446/http://www.prescod.net/rest/restmail/)

Also interesting:

[http://code.google.com/p/rmep/source/browse/wiki/References....](http://code.google.com/p/rmep/source/browse/wiki/References.wiki?spec=svn34&r=34)

<http://tools.ietf.org/html/draft-dusseault-httpmail-00>

<http://www.mailgun.com/>

------
bgnm2000
This is ridiculous - its like saying replace the car, because gas is too
expensive, so we're not doing it right. Its simple - people use email
incorrectly - they use it for task management (as you state). So maybe task
management tools (the one billion of them) aren't doing it right. If you use
email properly - solely as a ways of communication. Than it does it's job
correctly.

------
moe
The SMTP protocol is not going anywhere. Deal with it.

It's really straightforward to fix your griefs with e-mail: Write a MUA.

If it provides good value over normal e-mail clients _and_ handles normal
e-mail well then it will quickly become popular. If it's not backwards
compatible then it's just yet another "todo-app" and will very likely not take
off.

tldr; There is no such thing as "replace e-mail".

------
frossie
I can't shake the thought that if I could only forward an email to my trello
boards, (a la Evernote) my problems would be solved.

~~~
mikeknoop
This is something you can use Zapier for:
<https://zapier.com/zapbook/email/trello>

also Evernote: <https://zapier.com/zapbook/email/evernote>

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

------
senderpays
I want something along these lines: <http://cr.yp.to/im2000.html>

------
lelele
Being able to mark an email in a to-do system as "Waiting for reply" with an
expiration date would be useful. This way, such to-do system could alert you
when an email has not been answered to and prompt the next action.

Emails could be cross-linkable and have tags (among the tags, there could be
the ID of the project they belong to).

------
aychedee
Email is the worst solution to the problem of general communication except for
all the others.

In fact I think that quote goes a long way to explaining why email is so
wonderfully useful while also being annoying. Because it is so wonderfully
free and open. That's also it's downside

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

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

------
guynamedloren
Asana is working towards this (<http://www.asana.com>), though it's currently
a mostly closed system, not an open protocol.

------
pknerd
Umm make it more similar to current postal system?

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

------
michaelochurch
I think of email as a schema-less, dynamically-typed system for communication.
Anyone can send an email to anyone, and there's only one "type" for email (a
long string of blah)... but most emails are sent to too many people, and often
go unread. IT works, but it's a huge mess and it's unreliable. Also, the time
behavior of email isn't right for all purposes. Some emails are generally
useful 2 years later (and if you think the content is likely to be useful in 2
years, you probably shouldn't use email). The vast majority are not. Inbox
search solves the time problem, but it feels "bolted on". Inbox search isn't
an intrinsic fix but a late patch; it's using full-text search (which usually
works, but not always, because you might not remember any key phrases) because
there's no better solution right now.

So one thought is to consider something analogous to static typing, where
emails have types (we'd need a different word, because it's not exactly the
same concept) and these message types restrict (i.e. you might create a type T
for emails sent by user U under 500 characters). Unfortunately, I can't see a
way to design a system like this without making it massively complicated. The
problem here is that people are _already_ overloaded with email and adding any
piece of additional complexity is going to piss a lot of people off. Google
added typed edges with Circles in Google+-- clearly a good feature-- but they
took a lot of flak for G+ being "too complicated" for "mere mortals" to
understand because of Circles. When people are already fatigued and overloaded
and starting to get annoyed with the "tragedy of the commons" (all of this
being with email, and with social networks) even small bits of additional
complexity turn people off.

I think the final answer is: let email be. The problem isn't email itself.
There's a place for schemaless, dynamically-typed communication. It (or some
form of it) will always be useful and some part of how we communicate. The
problem with email is that people use it for too many things and in too many
sloppy ways, so the solution might be to identify communication patterns (for
example, persistent storage of knowledge) where email is not the best solution
and focus on those.

For some ideas, consider one problem with forums and social networks in
general: time behavior. Lots of content is generated, but quickly becomes
useless. How often do you read a 5-month-old thread on a message board or
social network? Occasionally, but not often. This imposes siloization by time,
so the value of the content can never grow faster than linearly as a function
of the amount of it. A lot of interesting discussions just won't happen if
they can't occur asynchronously. They won't get the critical mass.

One forum that I think deserves a lot of props for solving the time problem is
Quora. Quora has managed to structure itself in such a way that content
generated 12 months ago is still extremely valuable. It doesn't fall into
obscurity or become useless because it's "old", and it's pretty common that a
6-month-old answer will get a new comment actually worth reading. Quora is
also great in terms of how it handles new threads. On a typical message board,
an OP that doesn't get immediate response is just a failed thread. On Quora,
it's an open question. A good way to set it up, because not every OP that
doesn't get immediate attention deserves to die.

