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