Email has a lot of warts besides its obvious graces, especially when you look at the back-end of how emails are actually stored and transferred and authenticated. So I think we as programmers are naturally drawn to the idea of developing the email-killer. The central problem with the dreamers seems to be that they're not dreaming deeply enough.
Email is a communications multitool which leverages the whole human subconscious to effect its various uses: a human is supposed to know whether this is a "your boss demands that you do this" email or a "your friend wants you to look at her cute cat" email or "your uncle is ranting about fluoride in the water again" email. Most email killers do not and cannot eliminate this mental overhead. Graham only says "other people should be able to add to my todo list" -- he's not killing email, he's considering an email-aware todo list. That's very common. Skype is not an email killer precisely because it doesn't dream big enough: it is a realtime messaging protocol which hit it big because it worked with video. Trello is not an email killer precisely because it's for organizing groups. RSS is not an email killer because it only solves the limited problem of keeping aware of new content.
Email does all of these tasks -- poorly, but it does them. If you want to really kill email, you need to offer the core functionality effortlessly. Email II would understand "circles" of friends automatically, so that there is only an "inbox" for those people who are contacting you for the very first time. Like syndication, Email II would host the content on the publisher's web server to be downloaded whenever the client wants -- this has spam-deterrent effects, since the network doesn't take responsibility for the content. It would hopefully allow us to unify mailing lists. We can protect privacy with automatic cryptography; "chris::example.com" can stand for a public key which is stored on the example.com machines. The email killer needs to be good at segmenting messages so that we can say "This is the text of my invitation to a wedding, but it also comes with a standard-appointment-form where I describe where and when it is, so that it can be rapidly added to your 'upcoming dates' in the relevant social circle." (Since this must merge with dates and todo-lists, presumably example.com contains its own list of stuff which chris::example.com has stored for his own use.)
And I want to at this point admit defeat: because I think even those ideas are not daring enough. The email killer is probably going to have to do even more than all of that, and my own imagination becomes limited.
I have Gnus and Emacs on my computer because I have myself convinced that with enough macros I could create a completely automated version of my digital self. I imagine it would use a private/local NNTP server for all my notes, documentation, and organizational reference across computers, and emails would handle the communicate with the digital world even to the point of creating snapshots of online articles and posting comments on sites like Techcrunch under the articles using some combination of Jabber/cURL and my public Facebook profile.
Indeed, that email has everything inside is as much its strength as its weakness. It is as unlikely to go away as it is unlikely to remain unfiltered and unchanged.
Where the "killing" begins and the extension begins is basically fuzzy.
You could create an "Email II" that had present day email as its transmission layer or which had some other transmission layer as it's base. There's a wide area of innovation still available here.
This. It's email clients that are broken, not email.
For example, the most imaginative thing we can do with long email threads appears to be to flatten them and render them as a list.
Not to mention filtering and categorizing: in gmail, you can't even check in a filter if someone is in your contacts -- your gmail contacts -- let alone whether they fall into a particular contact group.
Yes, email clients are "broken". It is "easy to see" that fixing them is the key to really useful communication.
The weird thing is that any time you get one of these "broken" mediums, its users nonetheless become adapted to it. Even the stupidest original behavior becomes a part of a common, even socially, understood medium and changing it thus becomes harder.
An old girlfriend of mine was not terribly computer literate but understood the trick of clicking on an email link in Internet Explorer, having an outlook express window come up and then copying the resulting email-address to her webmail account to send an email. Once she learned this trick, she was far less concerned about the round-about-clunkiness involved in the whole process than I would be. It was just "how computers worked" and a simpler process she didn't know would quite possibly confuse her. She probably wouldn't even know that Outlook Express was an email client itself, for example.
Yes, Email might be ugly on the backend but that matters none at all. The client is obviously what is broken here, we are using the same client paradigm as when a handful of people had an email address! At the very least a better email client should do this:
1) Categorize notifications. Use the common web services as a base, and then look for obvious signs of repeated messages of the same type.
2) Prioritize people who are in your contact list. In fact this functionality should be broken out as a separate app. Actually, the same app that we current only use for text messages. I could rant on this for days; why in the hell are apps separated by what protocol they use rather than what the use case is? Ridiculous!
Spot on, this is what we do on www.post.fm (sorry for the plug) - organize your email around people & organizations, and then offer distinct user experiences based on various use cases (going through notifications, participating in threads or groups or chatting one-on-one with people you know).
This HN post shows how passionate people still are about email. I have to admit reading the comments has been like reading through my own thoughts for the past 2 years we've been working on this. I can't wait to share what we've done with all of you.
PS Email is indeed great. The protocols - not so much. Unfortunately most email clients are limited to using IMAP as the email API, which in some ways limits what they can do with email. Hotmail started as (and probably still is) just an html client for IMAP. So the UI is built around IMAP functions - get a list of headers, etc. Forget running sophisticated SQL queries against your inbox, the user experience is dictated by the API designers - never a good choice.
That's the key right there, I think. The email-killer is not some wild off-the-wall idea with a zany name that tries to pretend email never happened; it is email II. It is still email- just, the email of the future.
Come to think of it, you see this trend in a lot of tech history. The successor is a descendant, rather than usurper.
We've got to give Gmail the credit of Email II. Think about how much better Gmail was than what existed prior. Would you ever work at an institution that didn't use threading? Never!
I'll be honest - XMPP fits this description pretty well, at least as far as I read it right now. Most clients don't seem to understand this but that seems tractable.
Comments
Email has a lot of warts besides its obvious graces, especially when you look at the back-end of how emails are actually stored and transferred and authenticated. So I think we as programmers are naturally drawn to the idea of developing the email-killer. The central problem with the dreamers seems to be that they're not dreaming deeply enough.
Email is a communications multitool which leverages the whole human subconscious to effect its various uses: a human is supposed to know whether this is a "your boss demands that you do this" email or a "your friend wants you to look at her cute cat" email or "your uncle is ranting about fluoride in the water again" email. Most email killers do not and cannot eliminate this mental overhead. Graham only says "other people should be able to add to my todo list" -- he's not killing email, he's considering an email-aware todo list. That's very common. Skype is not an email killer precisely because it doesn't dream big enough: it is a realtime messaging protocol which hit it big because it worked with video. Trello is not an email killer precisely because it's for organizing groups. RSS is not an email killer because it only solves the limited problem of keeping aware of new content.
Email does all of these tasks -- poorly, but it does them. If you want to really kill email, you need to offer the core functionality effortlessly. Email II would understand "circles" of friends automatically, so that there is only an "inbox" for those people who are contacting you for the very first time. Like syndication, Email II would host the content on the publisher's web server to be downloaded whenever the client wants -- this has spam-deterrent effects, since the network doesn't take responsibility for the content. It would hopefully allow us to unify mailing lists. We can protect privacy with automatic cryptography; "chris::example.com" can stand for a public key which is stored on the example.com machines. The email killer needs to be good at segmenting messages so that we can say "This is the text of my invitation to a wedding, but it also comes with a standard-appointment-form where I describe where and when it is, so that it can be rapidly added to your 'upcoming dates' in the relevant social circle." (Since this must merge with dates and todo-lists, presumably example.com contains its own list of stuff which chris::example.com has stored for his own use.)
And I want to at this point admit defeat: because I think even those ideas are not daring enough. The email killer is probably going to have to do even more than all of that, and my own imagination becomes limited.
I have Gnus and Emacs on my computer because I have myself convinced that with enough macros I could create a completely automated version of my digital self. I imagine it would use a private/local NNTP server for all my notes, documentation, and organizational reference across computers, and emails would handle the communicate with the digital world even to the point of creating snapshots of online articles and posting comments on sites like Techcrunch under the articles using some combination of Jabber/cURL and my public Facebook profile.
But I just never get around to learning elisp.
Indeed, that email has everything inside is as much its strength as its weakness. It is as unlikely to go away as it is unlikely to remain unfiltered and unchanged.
Where the "killing" begins and the extension begins is basically fuzzy.
You could create an "Email II" that had present day email as its transmission layer or which had some other transmission layer as it's base. There's a wide area of innovation still available here.
This. It's email clients that are broken, not email.
For example, the most imaginative thing we can do with long email threads appears to be to flatten them and render them as a list.
Not to mention filtering and categorizing: in gmail, you can't even check in a filter if someone is in your contacts -- your gmail contacts -- let alone whether they fall into a particular contact group.
I feel like that's weirdly true and false.
Yes, email clients are "broken". It is "easy to see" that fixing them is the key to really useful communication.
The weird thing is that any time you get one of these "broken" mediums, its users nonetheless become adapted to it. Even the stupidest original behavior becomes a part of a common, even socially, understood medium and changing it thus becomes harder.
An old girlfriend of mine was not terribly computer literate but understood the trick of clicking on an email link in Internet Explorer, having an outlook express window come up and then copying the resulting email-address to her webmail account to send an email. Once she learned this trick, she was far less concerned about the round-about-clunkiness involved in the whole process than I would be. It was just "how computers worked" and a simpler process she didn't know would quite possibly confuse her. She probably wouldn't even know that Outlook Express was an email client itself, for example.
That's true. But I think this argues that GMail and Outlook will remain stagnant, not that email will stagnant.
Yes, Email might be ugly on the backend but that matters none at all. The client is obviously what is broken here, we are using the same client paradigm as when a handful of people had an email address! At the very least a better email client should do this:
1) Categorize notifications. Use the common web services as a base, and then look for obvious signs of repeated messages of the same type.
2) Prioritize people who are in your contact list. In fact this functionality should be broken out as a separate app. Actually, the same app that we current only use for text messages. I could rant on this for days; why in the hell are apps separated by what protocol they use rather than what the use case is? Ridiculous!
Spot on, this is what we do on www.post.fm (sorry for the plug) - organize your email around people & organizations, and then offer distinct user experiences based on various use cases (going through notifications, participating in threads or groups or chatting one-on-one with people you know).
This HN post shows how passionate people still are about email. I have to admit reading the comments has been like reading through my own thoughts for the past 2 years we've been working on this. I can't wait to share what we've done with all of you.
PS Email is indeed great. The protocols - not so much. Unfortunately most email clients are limited to using IMAP as the email API, which in some ways limits what they can do with email. Hotmail started as (and probably still is) just an html client for IMAP. So the UI is built around IMAP functions - get a list of headers, etc. Forget running sophisticated SQL queries against your inbox, the user experience is dictated by the API designers - never a good choice.
I requested an invite (same name as I go by here), would love to check out your service.
Email II
That's the key right there, I think. The email-killer is not some wild off-the-wall idea with a zany name that tries to pretend email never happened; it is email II. It is still email- just, the email of the future.
Come to think of it, you see this trend in a lot of tech history. The successor is a descendant, rather than usurper.
Email III
We've got to give Gmail the credit of Email II. Think about how much better Gmail was than what existed prior. Would you ever work at an institution that didn't use threading? Never!
I'll be honest - XMPP fits this description pretty well, at least as far as I read it right now. Most clients don't seem to understand this but that seems tractable.
Outside a work environment we already have e-mail killer — it is called facebook.
Facebook is a productivity killer, but it does POP email as well.