I would only optimize it for business users. Shorten the text (maybe force that even with AI or limitations, keep it async, chat is too sync). If you follow this rules Emails get a lot more productive. I like the simple adobtable approach of Emails in the "GitLab handbook" https://about.gitlab.com/handbook/
I wouldn't say nothing. Discord and Slack are making a serious dent into one of the primary use cases of email. Facebook has also entirely replaced email in f&f communication. Twitter+Facebook have mostly replaced product newsletters. It's also slowly-but-surely being phased out in identity confirmation, by oauth2 (which is a really, really sad thing given the proprietary lockin of oauth2).
Nothing will replace email altogether any time soon but if you offer a better tool for one of the many, many use cases it has, people will switch. Email became the default means of communication because it was the only way to communicate; it's not anymore.
What's really unfortunate is that everything I have listed is proprietary. We're putting our communication channels (both as users and as companies) in the hands of private companies that could shut us down at any moment.
I think your right. There might be a chance that one day an all encompassing communication mechanism that can do video, audio, group and 1on1 data as well as instant and fire and forget could potentially slowly replace email given time and delivery.
But how it gets delivered matters, it can't be locked up in IP and sold by a company because its competing with free and open standard and that means there isn't any practical money in it directly. The only competitor to email is the updated open standard that is better.
There can be a better email standard, it can be delivered in a more modern way and have the "isms" improved and be able to do it all. What it can't be is anything but another open standard and free.
Email is tough to kill because it's not a company or a product, it's a decentralized set of standards. Email sucks in a lot of ways, but it's simple, works everywhere, and it's baked into a lot of places (confirmation emails, password reset emails, alert emails, etc). There are better technologies out there like messaging and slack, but they're controlled by companies and not open/decentralized, and while they have integrations, they aren't baked into a lot of places (e.g. no Amazon confirmation slack messages or bank alerts through FB messenger).
Imagine trying to kill XML because JSON is better...nearly impossible. Email may slowly die over time, but I don't think it's likely you can kill it outright.
Yes, the fact that you can send email to people who aren't using your email system is the main thing that's keeping chat services stuck as part of a company's communication tools and not being the entire (or almost entire) thing.
I actually wrote the easy 50% of email back compatibility for a chat app once - it wasn't as hairy as I expected it was going to be. Everyone has a unique username (or at least username+org pair) so use that to generate an email address for them. Similarly, generate an email address for every group/room. When you receive an email for one of those addresses, use the from headers to find/create a new pseudo-user and dump the body of the email in as a chat message. When someone writes in chat that has a pseudo-user as one of the people watching that chat, send them an email with that text and throw in a few previous messages as a fake reply chain for context.
There are a lot of hairy details about thread management and making sure you don't send pseudo-users too many emails and dealing with all the messed up headers that different platforms send you and trying to only extract the actual message and not the signature/replies from an email and attachments so on that I only worked on a little before the whole thing was shuttered. But it was really cool. Email users tended not to notice that anything was different (they're used to email looking weird from various services) and chat users got to stay in chat that was a little awkward instead of having to switch to a different tool entirely to talk to people outside the organisation. (And, if all the different chat services started doing it, you'd get really janky chat federation for free!) And it lets you get a lot of stuff that gets made as Slack integrations for free, too. Why bother setting up a bot to post to chat when a Jenkins build fails when you can just give Jenkins your dev chat's email address and let it send emails?
I guess the real question is "How feasible is it to remove or change the things that suck about email while keeping and possibly enhancing the good parts?" And I suppose the answer is that it's technically possible, but would be expensive, painful, and require a lot of cooperation.
Email is tough to kill because it's not a company or a product, it's a decentralized set of standards.
I think this is the answer to the question. Google and Microsoft e-mail monoculture could kill e-mail. Google Mail is well-known have incompatible IMAP extensions. I guess that if the two or three major players get a marketshare that is large enough, they'll start dropping more and more 3rd party mail ('just a glitch in the reputation system') until e-mail outside Google Mail and Exchange Online is not reliable enough anymore to bet your company business on.
Luckily, we are still far from that point, but with companies and universities switching to Google Apps and Office 365 en masse...
You can replace certain use cases of email, but you wont replace all the use cases at once.
For business opportunities might be around workflow and
decisionmaking.
Slack dramatically reduced my email volume by replacing a use case that email handled badly, for example.
A consumer analogy, Facebook replaced a bunch of email use cases. I still have a friend who sends out email updates with photos while traveling, for example.
SMS and messaging apps, of course.
Someone could do a map like this list of companies that replaced specific use cases of Craigslist
For personal uses, email has already been disrupted by Facebook, WhatsApp, and instant messengers overall. Longform newsletters are the last real use case, because RSS failed to disrupt it. Facebook and others are working on that as well.
Facebook messages are lock-in. Back when I used it a lot, you could connect via XMPP client. But there is now no way to get your own messages out of their eco-system that I am aware off. It's like switching a dumb-cellphone to another cellphone, you loose all your old SMS (if the aren't stored on the SIM card and there is no PC link cable+software). Open standards like IRC, email, XMPP prevent something like this to happen.
Nothing... I would like to see better interfaces for email. I am looking for 2 things. Conversational layouts so long message chains can be easier to read and review (this is difficult as not everyone in a cc'd email chain gets each email). A better way to manage multiple accounts from one inbox.
I completely second byoung2's comment.
When we say email , the thing we refer to would be free email services for personal use or inbox hell at work.
The same question without Gmail,Yahoo mail and other is easier to answer.
SMTP might be here to stay, but a low cost protocol independent messaging protocol with an Identity layer can and will come along.
Why does no official comm happen on email? No ID validation.
Maybe PKI can help.
Solution will either be use case by usecase or platform change like FB or chat
You're thinking about it the wrong way. First ask yourself what's wrong with email and why does it need to be disrupted? What problem are we actually trying to solve by replacing email.
Email is a powerful tool for asynchronous communication and it's here to stay. The way in which we interact with email may change over time as user interfaces change. We've gone from desktop to mobile and soon there may be some other dominant platform.
To answer my own question. In large corporations email is typically still used to announce or notify at scale. So what we're really looking for is a way to strip out this notification aspect. That's basically just an enterprise version of twitter with an opt-in model for streams which allows you to keep track of what everyone's doing in the organisation without having your inbox spammed. Notice I'm not talking about the collaborative use of email since that's already being solved by tools like Asana, Slack and Atlassian.
does Slack have an on premise option? because I think many corporate customers would definitely pay for it, despite all the cloud/saas hype. there are still orgs out there that dont want their comms outside their premises.
Having used team chats based on Jabber, IRC, Slack (in that chronological order), there is a huge difference. Jabber and IRC have always been pure chats, whereas Slack is the first chat platform where people actually use integrations and bots to a large extent. (Also, Jabber/IRC doesn't have /remind, my personal killer feature about Slack.)
To your point, I think we've already see a lot of products that chip away at email, but we're unlikely to see full replacement. Email is the lowest common denominator way of sending something over the internet. Lots of my tasks started with email but moved into other products: keeping in touch with old friends (Facebook), sending/collaborating on spreadsheets (GDrive), asking coworkers a question (Slack).
An email client that aggressively advocates for and implements new protocol features. Browsers accelerated web standards and stole market share by doing this.
I would like to see an email client with an edit button for messages. I have already thought a lot about this feature [0]. Feel free to comment on the issue.
One of my coworkers was fantasizing the other day about starting a company where they don't send any internal emails. His plan involved prioritizing face-to-face communication, dedicated Slack channels, and a suite of tools that made it easier to index, and search across Slack. It was an interesting thought experiment, but it broke down in a lot of areas, and I think our conclusions were:
1) It would only have a chance of working in a small organization with a single team, or few teams that communicate regularly and effectively.
2) It's one thing to favor other channels of communication, but outright banning of email didn't have a lot of benefits other than forcing people to favor said alternate channels.
Well, basically we don't use email for internal communications. The only emails I send to or receive from coworkers involve some kind of external parties that only work with email.
(Ok, I admit there are a few (very, very few) reports we send by mail to archive them).
I work at a company with about 25 employees, some of which are remote. All communication happens on Slack, Basecamp and Github. We also have Friday afternoon drinks to catch up in real life. It works well. Can't remember when I last received an internal email.
External communication does still happen over email, that won't change any time soon I think.
I love email. My only problem with email is that it's too difficult to reliably run your own server with a Gmail quality interface. I have Fastmail for email on my own domain and it is quite nice but the more experience I get the less I want companies involved in being the gatekeepers to my critical and personal information.
Probably a social electric car with AI, and a voice interface. The driver's seat will be a standing a desk, and the dashboard will use flat design. Data storage will be handled with Blockchain, and devops will keep everything running smoothly using Github and Docker and React.
I think that Slack would argue that they are disrupting email. We have many fewer internal emails at work now - most are directed at clients.
Facebook Messenger, WhatsApp, etc. Are strong contenders for replacing email to friends.
Not trying to avoid your question, but I think the future of email isn't a better protocol or SMTP client enhancement, it's apps that provide a better way of communicating a given task.
As it turns out, the major feature of email (being able to message anyone) is also a huge drawback (communications inundated with spam).
Possibly email addresses that won't accept more than 200 plain text chars, so real people get to the point quickly and spam becomes easier to determine.
We have viable replacements - our habits just haven't caught up to the tools.
Corporate e-mail assigns each employ a revocable identity, groups employees into roles, and allows people to have private and public conversations. Tools like Slack have become ubiquitous at software companies, and they provide the _exact_ same functionality, with a foundation on realtime communication that I believe is more productive. We still use e-mail for corporate announcements and engagement when we really don't have to, and I think we'll stop as we get better at it.
e-mail is just one piece of the corporate communication story though - document creation and storage are another "standard" feature. Slack's "Plus" plan is $12.50/user/month [0]. Premium G-Suite and Microsoft's Office 365 are $10/user/month and $12.50/user/month [1] [2]. You can tell just be the price tags and features that these companies are competing for shares of the same corporate communication pie.
Slack right now is a player partly because the can backfill their shortcomings here by integrating with G-Suite tools. You can see Slack trying to backfill with Posts, Slack Calls, and I'd bet they're working on other high leverage features (they have a lot of catch-up to do) to stay competitive as the core of their platform faces competition from the likes of Microsoft Teams and open source alternatives [3].
On thing e-mail is better at is person to person contact outside the context of any organization. e-mail succeeds because I need one piece of information to contact you (a public address), and I can be contacted by one public address as well, no matter the tribe (gmail, outlook, etc.). Maybe a global chatroom with name-spaced public address would be a decent alternative?
The thing that will kill email is its lack of encryption. I'm surprised to see on here that nobody is talking about encryption, but it's very important. Most companies are not using it, and the email encryption options available are far too clunky to be used effectively. Key negotiation needs to be built into the protocol, ala Signal.
I don't think it can be killed. I do think you can make an email++, but agree with the other comment that it would have to only be for business. I think the thing that is missing is more structure and management capabilities. The only problem is how do you have it be interoperable with an email clients that don't have your new thing. One thing you have to start with is what are the things that really really suck with email, imo: inability to opt-out of threads, no ability to say what type of email it is (INFO, REQUEST, PITCH, COMPLETE, etc.), no ability say that a response/work is required and by whom and by what date, hard to not lose the important facts of the email after 25 replies, etc....
Quite frankly I can think of a bunch of other things as well. I don't have time right now but I would look at adding structured data at the top of the email that you can parse but shows up nicely as text in other clients, for example (assuming html email, just off the top....)
<div style="color:white;">
<div id="type">REQUEST</div>
<div id="response">No</div>
<div id="duedate">14Feb2016</div>
<div id="assignee">bob@example.com</div>
<div id="keypoint-1">We don't have a good backup procedure</div>
<div id="keypoint-2">We've never tested our backups</div>
<div id="keypoint-3">We've never built a clone network from our backup</div>
</div>
You can now parse/search/filter based on this data. You can manage tasks right in email and have a button to say "done" that sends an email back to the originator that they know it is done. There are a lot of other things too but I need to go do work now :(. I'll monitor this thread if you want to discuss further. (/sigh, I wish HN had integrated private messages)
An email can contain multiple arbitrary payloads. It's almost like HTTP, except it's asynchronous. We already have the infrastructure to deliver messages from anyone to anyone. Why keep trying to destroy it when we could take advantage of the existing infrastructure instead? I don't see anyone rallying to disrupt HTTP. Why all the obsession with disrupting email?
We could use different Content-Types to embed all sorts of structured information in an email, and standardize the hell out of it. A schedule for an event. An item to go on your TODO list. A link to click for confirmation. If you can express it in JSON, you can attach it to an email. And the resulting messages will be 100% backward compatible with old email clients, just like newer versions of HTTP.
There are endless possibilities for email as long as you don't try to get everyone on your own proprietary platform. Otherwise you will be just another messaging service that has nothing to do with email, and email users will happily ignore you. Don't fall into that pitfall. You need to make your solution an essential part of people's email workflow, rather than trying to steer people toward a different workflow.
The problem is the usual with a federated protocol: adding a feature requires you to extend all the clients, which does not happen. See for example PGP.
The features are completely opt-in. If you don't want to link your email to your schedules or TODO list, you don't need to do anything. The same information should be present in a human-readable format in the body of the email anyway. (YAML might be better than JSON for this purpose.)
62 comments
[ 3.0 ms ] story [ 156 ms ] threadI would only optimize it for business users. Shorten the text (maybe force that even with AI or limitations, keep it async, chat is too sync). If you follow this rules Emails get a lot more productive. I like the simple adobtable approach of Emails in the "GitLab handbook" https://about.gitlab.com/handbook/
Nothing will replace email altogether any time soon but if you offer a better tool for one of the many, many use cases it has, people will switch. Email became the default means of communication because it was the only way to communicate; it's not anymore.
What's really unfortunate is that everything I have listed is proprietary. We're putting our communication channels (both as users and as companies) in the hands of private companies that could shut us down at any moment.
But how it gets delivered matters, it can't be locked up in IP and sold by a company because its competing with free and open standard and that means there isn't any practical money in it directly. The only competitor to email is the updated open standard that is better.
There can be a better email standard, it can be delivered in a more modern way and have the "isms" improved and be able to do it all. What it can't be is anything but another open standard and free.
Imagine trying to kill XML because JSON is better...nearly impossible. Email may slowly die over time, but I don't think it's likely you can kill it outright.
I actually wrote the easy 50% of email back compatibility for a chat app once - it wasn't as hairy as I expected it was going to be. Everyone has a unique username (or at least username+org pair) so use that to generate an email address for them. Similarly, generate an email address for every group/room. When you receive an email for one of those addresses, use the from headers to find/create a new pseudo-user and dump the body of the email in as a chat message. When someone writes in chat that has a pseudo-user as one of the people watching that chat, send them an email with that text and throw in a few previous messages as a fake reply chain for context.
There are a lot of hairy details about thread management and making sure you don't send pseudo-users too many emails and dealing with all the messed up headers that different platforms send you and trying to only extract the actual message and not the signature/replies from an email and attachments so on that I only worked on a little before the whole thing was shuttered. But it was really cool. Email users tended not to notice that anything was different (they're used to email looking weird from various services) and chat users got to stay in chat that was a little awkward instead of having to switch to a different tool entirely to talk to people outside the organisation. (And, if all the different chat services started doing it, you'd get really janky chat federation for free!) And it lets you get a lot of stuff that gets made as Slack integrations for free, too. Why bother setting up a bot to post to chat when a Jenkins build fails when you can just give Jenkins your dev chat's email address and let it send emails?
I guess the real question is "How feasible is it to remove or change the things that suck about email while keeping and possibly enhancing the good parts?" And I suppose the answer is that it's technically possible, but would be expensive, painful, and require a lot of cooperation.
I think this is the answer to the question. Google and Microsoft e-mail monoculture could kill e-mail. Google Mail is well-known have incompatible IMAP extensions. I guess that if the two or three major players get a marketshare that is large enough, they'll start dropping more and more 3rd party mail ('just a glitch in the reputation system') until e-mail outside Google Mail and Exchange Online is not reliable enough anymore to bet your company business on.
Luckily, we are still far from that point, but with companies and universities switching to Google Apps and Office 365 en masse...
For business opportunities might be around workflow and decisionmaking.
Slack dramatically reduced my email volume by replacing a use case that email handled badly, for example.
A consumer analogy, Facebook replaced a bunch of email use cases. I still have a friend who sends out email updates with photos while traveling, for example.
SMS and messaging apps, of course.
Someone could do a map like this list of companies that replaced specific use cases of Craigslist
https://www.cbinsights.com/blog/craigslist-unbundling/
The op's question was about business though.
I have used Slack but it doesn't come anywhere close to emails in terms of ease of use, especially for people in non-technical fields.
SMTP might be here to stay, but a low cost protocol independent messaging protocol with an Identity layer can and will come along.
Why does no official comm happen on email? No ID validation. Maybe PKI can help. Solution will either be use case by usecase or platform change like FB or chat
-JWZ
Email is a powerful tool for asynchronous communication and it's here to stay. The way in which we interact with email may change over time as user interfaces change. We've gone from desktop to mobile and soon there may be some other dominant platform.
To answer my own question. In large corporations email is typically still used to announce or notify at scale. So what we're really looking for is a way to strip out this notification aspect. That's basically just an enterprise version of twitter with an opt-in model for streams which allows you to keep track of what everyone's doing in the organisation without having your inbox spammed. Notice I'm not talking about the collaborative use of email since that's already being solved by tools like Asana, Slack and Atlassian.
[0] https://about.mattermost.com/ [1] https://zulip.org/server.html
I would like to see an email client with an edit button for messages. I have already thought a lot about this feature [0]. Feel free to comment on the issue.
[0] https://github.com/deckar01/amend-mail/issues/1
1) It would only have a chance of working in a small organization with a single team, or few teams that communicate regularly and effectively.
2) It's one thing to favor other channels of communication, but outright banning of email didn't have a lot of benefits other than forcing people to favor said alternate channels.
(Ok, I admit there are a few (very, very few) reports we send by mail to archive them).
External communication does still happen over email, that won't change any time soon I think.
Although I didn't mention what email client you are using, we will be glad to give us suggestion what Gmail feature from you are most needed?
Disclaimer: I'm Mailtemi (email) app, developer.
This would help people manage their email better.
Outlook and exchange are getting better, but still lacking.
Gmail has it's threads which work most of the time. Both have proprietary tagging which is not IMAP compatible, which is why Thunderbird suffers.
If Thunderbird could handle Exchange and Gmail proprietary nuances it'd be perfect.
2) Better email etiquette
The easier your email is to read and comprehend the more likely it'll get responded to.
Fix / improve these two then this need to "disrupt email" would fade.
This, it's all about the UI/UX. Though I found Windows 10 default client quite nice for non professional use.
Facebook Messenger, WhatsApp, etc. Are strong contenders for replacing email to friends.
Not trying to avoid your question, but I think the future of email isn't a better protocol or SMTP client enhancement, it's apps that provide a better way of communicating a given task.
As it turns out, the major feature of email (being able to message anyone) is also a huge drawback (communications inundated with spam).
Oh, and secure end-to-end encryption that is simple to set up and use safely.
Corporate e-mail assigns each employ a revocable identity, groups employees into roles, and allows people to have private and public conversations. Tools like Slack have become ubiquitous at software companies, and they provide the _exact_ same functionality, with a foundation on realtime communication that I believe is more productive. We still use e-mail for corporate announcements and engagement when we really don't have to, and I think we'll stop as we get better at it.
e-mail is just one piece of the corporate communication story though - document creation and storage are another "standard" feature. Slack's "Plus" plan is $12.50/user/month [0]. Premium G-Suite and Microsoft's Office 365 are $10/user/month and $12.50/user/month [1] [2]. You can tell just be the price tags and features that these companies are competing for shares of the same corporate communication pie.
Slack right now is a player partly because the can backfill their shortcomings here by integrating with G-Suite tools. You can see Slack trying to backfill with Posts, Slack Calls, and I'd bet they're working on other high leverage features (they have a lot of catch-up to do) to stay competitive as the core of their platform faces competition from the likes of Microsoft Teams and open source alternatives [3].
On thing e-mail is better at is person to person contact outside the context of any organization. e-mail succeeds because I need one piece of information to contact you (a public address), and I can be contacted by one public address as well, no matter the tribe (gmail, outlook, etc.). Maybe a global chatroom with name-spaced public address would be a decent alternative?
[0] https://slack.com/pricing [1] https://gsuite.google.com/intl/en_us/pricing.html [2] https://products.office.com/en-us/compare-all-microsoft-offi... [3] http://venturebeat.com/2015/11/27/5-open-source-alternatives...
Quite frankly I can think of a bunch of other things as well. I don't have time right now but I would look at adding structured data at the top of the email that you can parse but shows up nicely as text in other clients, for example (assuming html email, just off the top....)
<div style="color:white;"> <div id="type">REQUEST</div> <div id="response">No</div> <div id="duedate">14Feb2016</div> <div id="assignee">bob@example.com</div> <div id="keypoint-1">We don't have a good backup procedure</div> <div id="keypoint-2">We've never tested our backups</div> <div id="keypoint-3">We've never built a clone network from our backup</div> </div>
You can now parse/search/filter based on this data. You can manage tasks right in email and have a button to say "done" that sends an email back to the originator that they know it is done. There are a lot of other things too but I need to go do work now :(. I'll monitor this thread if you want to discuss further. (/sigh, I wish HN had integrated private messages)
An email can contain multiple arbitrary payloads. It's almost like HTTP, except it's asynchronous. We already have the infrastructure to deliver messages from anyone to anyone. Why keep trying to destroy it when we could take advantage of the existing infrastructure instead? I don't see anyone rallying to disrupt HTTP. Why all the obsession with disrupting email?
We could use different Content-Types to embed all sorts of structured information in an email, and standardize the hell out of it. A schedule for an event. An item to go on your TODO list. A link to click for confirmation. If you can express it in JSON, you can attach it to an email. And the resulting messages will be 100% backward compatible with old email clients, just like newer versions of HTTP.
There are endless possibilities for email as long as you don't try to get everyone on your own proprietary platform. Otherwise you will be just another messaging service that has nothing to do with email, and email users will happily ignore you. Don't fall into that pitfall. You need to make your solution an essential part of people's email workflow, rather than trying to steer people toward a different workflow.