Ask HN: What could disrupt email?
As the defacto standard for business and corporate communication?
62 comments
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.
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.
Zulip and Mattermost are alternatives that can be hosted (they're both open source software).
[0] https://about.mattermost.com/ [1] https://zulip.org/server.html
[0] https://about.mattermost.com/ [1] https://zulip.org/server.html
It's called IRC/Jabber + whatever web/GUI/CLI UI is desired. Many companies deploy it internally.
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).
Nothing. Everybody tried.
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 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.
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.
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.
Does email need disruption? I have not faced any problem with emails as a form of business communication.
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.
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.
I use email every day for work in communication with clients and co-workers. I can't think of anything about email's principal concept which needs disruption (ie. asynchronous communication). I certainly can't think of any value which could be made above that which email provides and at such little cost. I think I can safely say our privately owned company uses email because it satisfies all our requirements: messages are fast, works with all manner of media we need, everybody's (clients, co-workers, vendors) has an email account, and client software is batteries included. I could go on.
That said, I think improvements could be done on the software side. Integration with applications in meaningful task-related ways (some apps I use have contact list, but the app can't infer what should go into my email's body given the context of the windows I have open). For me I could imagine OS level innovations improving my _writing_ experience.
That said, I think improvements could be done on the software side. Integration with applications in meaningful task-related ways (some apps I use have contact list, but the app can't infer what should go into my email's body given the context of the windows I have open). For me I could imagine OS level innovations improving my _writing_ experience.
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">[email protected]</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)
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">[email protected]</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)
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.
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 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?
> Email sucks in a lot of ways
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 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...
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...
There's a fairly well known graphic of all the companies that have taken chunks of Craigslist and to varying degrees supplanted them:
http://static3.businessinsider.com/image/4dd4d1cf4bd7c8c90f0...
Email is being disrupted similarly.
Slack/Chat -> Intra-team communications. But also sales inquiries (those ubiquitous: 'We're here to help!' toaster style popups on every company site) and status notifications (for instance StatusPage was bought by Atlassian in large part to merge into HipChat).
Internal Social -> Many people are familiar with Yammer (which is FB for within a company), but other services like Salesforce, etc have versions of this internally. You could also consider services like Jive in this.
External Social -> I've run some fairly substantial mailing lists and social accounts. For something like a non emergency information sender ("Weekly GoLang Tips!") it's about evenly split with people signing up for the newsletter vs signing up on Twitter.
http://static3.businessinsider.com/image/4dd4d1cf4bd7c8c90f0...
Email is being disrupted similarly.
Slack/Chat -> Intra-team communications. But also sales inquiries (those ubiquitous: 'We're here to help!' toaster style popups on every company site) and status notifications (for instance StatusPage was bought by Atlassian in large part to merge into HipChat).
Internal Social -> Many people are familiar with Yammer (which is FB for within a company), but other services like Salesforce, etc have versions of this internally. You could also consider services like Jive in this.
External Social -> I've run some fairly substantial mailing lists and social accounts. For something like a non emergency information sender ("Weekly GoLang Tips!") it's about evenly split with people signing up for the newsletter vs signing up on Twitter.
I don't think there is an issue with email per se. It's more that there hasn't been much "evolution" in its use.
Though, Google and other companies have definitely tried to make email "better".
After an elaborate phase of talking to hundreds of companies, I've created a platform that has the approach of "collaborative email". It's providing an additional layer to email that helps companies to keep track of all those customer emails (you can check it out at http://helpmonks.com).
In any case, I think in adding additional service around email is where the real disruption lies.
Though, Google and other companies have definitely tried to make email "better".
After an elaborate phase of talking to hundreds of companies, I've created a platform that has the approach of "collaborative email". It's providing an additional layer to email that helps companies to keep track of all those customer emails (you can check it out at http://helpmonks.com).
In any case, I think in adding additional service around email is where the real disruption lies.
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.
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.
Your coworker must be a masochist, because replacing email by constant meetings doesn't sound like much of a fantasy to me.
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).
(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.
External communication does still happen over email, that won't change any time soon I think.
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
https://www.cbinsights.com/blog/craigslist-unbundling/
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/
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.
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.
The op's question was about business though.
The op's question was about business though.
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
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
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.
[0] https://github.com/deckar01/amend-mail/issues/1
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
What's wrong with email? It works fine for decades. SMTP, (POP3) and IMAP are fine protocols.
Please disrupt chat instead, with a proper protocol. A new non-XML based XMPP version maybe? Anyway the big players need to support it. Now we have all these proproitary chat apps (FB/WhatsApp, WeChat, SnapChat, Skype, Hangout, etc.) that are incompatible closed eco-systems. Maybe we should just disrupt chat by using the email protocols and infrastructure ;)
Please disrupt chat instead, with a proper protocol. A new non-XML based XMPP version maybe? Anyway the big players need to support it. Now we have all these proproitary chat apps (FB/WhatsApp, WeChat, SnapChat, Skype, Hangout, etc.) that are incompatible closed eco-systems. Maybe we should just disrupt chat by using the email protocols and infrastructure ;)
Please don't "disrupt" the last open standard alive in online communication.
Better email.
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.
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.)
I've just been setting up a new web server this last week, a shared host for a few friends and family, personal websites, a couple of side projects, etc.
The bit which drives me the most crazy is setting up email on it. All the sites need to be able to send occasional notification emails (WordPress, so password resets, etc). I hoped dragonfly mail daemon would be enough,. But we also need virtual host forwarding - if you email some addresses at one of the hosts, it should forward on to the right persons Gmail, or whatever. So we ended up with postfix. Which is reasonable easy - a hell of a lot easier to configure than sendmail or exim, but even still... I wish so much for a mail daemon with all the correct options for SRS, DKIM, SPF, SSL, TLS, greylisting, etc. Turned on by default, and yaml/toml configuration... I'm at the point of reading golang and python SMTP code and wanting to write one. Something like caddy for email.
Email is complex, there are so many edge cases and options. It's insane. Reading documentation is awful, as all daemon docs assume you know what all the acronyms mean, and that you understand all the various RFCs.
The bit which drives me the most crazy is setting up email on it. All the sites need to be able to send occasional notification emails (WordPress, so password resets, etc). I hoped dragonfly mail daemon would be enough,. But we also need virtual host forwarding - if you email some addresses at one of the hosts, it should forward on to the right persons Gmail, or whatever. So we ended up with postfix. Which is reasonable easy - a hell of a lot easier to configure than sendmail or exim, but even still... I wish so much for a mail daemon with all the correct options for SRS, DKIM, SPF, SSL, TLS, greylisting, etc. Turned on by default, and yaml/toml configuration... I'm at the point of reading golang and python SMTP code and wanting to write one. Something like caddy for email.
Email is complex, there are so many edge cases and options. It's insane. Reading documentation is awful, as all daemon docs assume you know what all the acronyms mean, and that you understand all the various RFCs.
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.
We're all likely to have some sort of a communication stream in our professional lives that needs regular attention from us for the foreseeable future. Right now, it's email.
I feel like most people who "dislike email" dislike it as a proxy for their unhappiness with their working environment and how the people around them communicate.
Email could probably do a better job of compensating for the poor communication habits of those we work with. In my experience, Slack exacerbates those bad habits. But with email, I don't think the medium is necessarily the problem. It's an asynchronous stream of stuff that needs our attention or that we want to have our attention. The protocol is reliable and nearly universal.
I feel like most people who "dislike email" dislike it as a proxy for their unhappiness with their working environment and how the people around them communicate.
Email could probably do a better job of compensating for the poor communication habits of those we work with. In my experience, Slack exacerbates those bad habits. But with email, I don't think the medium is necessarily the problem. It's an asynchronous stream of stuff that needs our attention or that we want to have our attention. The protocol is reliable and nearly universal.
Email itself, as with how Google is with Gmail and Inbox,which has reminders and interactive messages (Trello, Slack, etc.), the ability to use Google Drive for large attachments, and send money to friends.
If Gmail had a publishing platform, sort of like MailChimp, in which partners from large sites could use to gather analytics and craft messages with embedded content beyond the limits of typical messages. You could:
- reset your password with a click of a button and have it generated and stored by Google.
- chop up lengthy newsletters to contain only the content that you need.
- Convert threads with other Gmail users into chats, with threaded messaging.
This could reduce traffic to their site, though, making it less sticky. And it would work ideally in Chrome, unfortunately.
If Gmail had a publishing platform, sort of like MailChimp, in which partners from large sites could use to gather analytics and craft messages with embedded content beyond the limits of typical messages. You could:
- reset your password with a click of a button and have it generated and stored by Google.
- chop up lengthy newsletters to contain only the content that you need.
- Convert threads with other Gmail users into chats, with threaded messaging.
This could reduce traffic to their site, though, making it less sticky. And it would work ideally in Chrome, unfortunately.
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).
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).
Email is fine, don't disrupt it. Make it better instead.
Blackberry got it mostly right with Hub - get all your emails, messages, whatevers into one place and let you work out how you want to organise it all. Something like that but a bit smarter (like Gmail's auto sorting of promotions, updates etc).
If I could have one pane of glass to look at for my emails, slack/skype, text messages, social media (business related of course) - I'd happily pay money for that.
Blackberry got it mostly right with Hub - get all your emails, messages, whatevers into one place and let you work out how you want to organise it all. Something like that but a bit smarter (like Gmail's auto sorting of promotions, updates etc).
If I could have one pane of glass to look at for my emails, slack/skype, text messages, social media (business related of course) - I'd happily pay money for that.
1) Better email clients
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 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.
> 1) Better email clients
This, it's all about the UI/UX. Though I found Windows 10 default client quite nice for non professional use.
This, it's all about the UI/UX. Though I found Windows 10 default client quite nice for non professional use.
From time to time I hear about some startup that is going to "disrupt email." In my opinion email is something that works very well for asynchronous communication. What is their to disrupt?
If your expectation is real time/synchronous then email is simply the wrong choice of tool. That doesn't mean its lacking or needs to be "disrupted."
If your expectation is real time/synchronous then email is simply the wrong choice of tool. That doesn't mean its lacking or needs to be "disrupted."
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 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.
Hi, your opinion is what we tried to achieve.
Gmail UI experience with each IMAP service.
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.
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.
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?
[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...
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...
Honestly, I think Slack is doing a great job of eliminating massive email chains that should really be in a group chat. As for casual, slower communication, I don't think it's going anywhere. We still use paper mail after all.
Two things, 1) auto detect marketing email and remove or get it out of the way, 2) make replying a taskable thing. Those are my 2 major problems, too much junk mail and not having time right now to reply.
Something like HTTP2 for email and then companies using email as a low-level back-end for communication needs. Imagine FB posts backed by email. Chat backed by email. And so on. Pipe dream.
The removal of corporate bullshit signatures and legal disclaimers that are 10x the size of the actual email content.
Oh, and secure end-to-end encryption that is simple to set up and use safely.
Oh, and secure end-to-end encryption that is simple to set up and use safely.
Email has its problems, but it is one of the cornerstones of authentication messages exchange. Are you going to shake this one?
Another question is what technologies can be disrupted by being more like email? (Distributed, open standard, etc)
Social Media comes to mind.
Social Media comes to mind.
I don't know about disrupt but I sometimes message new business contacts on linkedin. It gets kind of annoying after a bit though.
“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”
-JWZ
-JWZ
Idea 1
========
A client that threat email as a chat message.
You enter your email and your password. You get chat timelines like in whatsapps/viber/kik/wechat/text message. You can just write and send (no topic, no inbox, etc).
This way you can use a reliable ID and messaging system to write messages as easily as text messages. But with none of the jailed env like whatsapps.
You can have reliable encryption with PGP. Share media with attachment (but with a simple UI). And it works with your regular email address, no need to create a new account. It works with anybody (every body has an email address). It works even with people not using the app.
To ensure it works with everybody, when you give your credentials it creates a special IMAP inbox with just the mails from this "disposable" emails to not pollute your real inboxes.
Idea 2 =======
Internal email address for a community
You create an email address, and only members of this community can get them, or write to each others. You can then give permissions to external services to write to you after approval. Non approved senders emails are rejected silently.
This system would be great for the government, where any citizen would have an official email address for life to communicate with the state. But you can't spam it. you can't write to your friends with it. If an actor negociate with the state (such as utilities providers), they can send your bills there. But no ads or they get their permission revoked.
Basically like an real life official inbox, but global, with only important content and virtual.
Of course you'll need to enforce 2-factor authentication on at the very minimum.
Idea 3 ======
Email integrated in a Planning + Note system. Right now we integrate notes and todo into email. I think the problem is backward. Emails are input you turn into TODO, notes and appointments in your calendards.
What I usually want is to be able to have a link to an email that works offline, which open my email client to this particular email. I used thunderlink addon for that because that's the only way to do it, but it sucks.
This link I would be able to paste into my workflow. Apps could use it to integrate a preview of the mail and attachments in the app, cache the mail, ask for notifications about the conversation, get callbacks for events (email deleted, marked as, moved to...) or tell the email client to archive the mail and prevent deletions.
This should work offline (I want to be able to get organized in the plane) and online (APIs => webhooks => cluster of integrated services).
A client that threat email as a chat message.
You enter your email and your password. You get chat timelines like in whatsapps/viber/kik/wechat/text message. You can just write and send (no topic, no inbox, etc).
This way you can use a reliable ID and messaging system to write messages as easily as text messages. But with none of the jailed env like whatsapps.
You can have reliable encryption with PGP. Share media with attachment (but with a simple UI). And it works with your regular email address, no need to create a new account. It works with anybody (every body has an email address). It works even with people not using the app.
To ensure it works with everybody, when you give your credentials it creates a special IMAP inbox with just the mails from this "disposable" emails to not pollute your real inboxes.
Idea 2 =======
Internal email address for a community
You create an email address, and only members of this community can get them, or write to each others. You can then give permissions to external services to write to you after approval. Non approved senders emails are rejected silently.
This system would be great for the government, where any citizen would have an official email address for life to communicate with the state. But you can't spam it. you can't write to your friends with it. If an actor negociate with the state (such as utilities providers), they can send your bills there. But no ads or they get their permission revoked.
Basically like an real life official inbox, but global, with only important content and virtual.
Of course you'll need to enforce 2-factor authentication on at the very minimum.
Idea 3 ======
Email integrated in a Planning + Note system. Right now we integrate notes and todo into email. I think the problem is backward. Emails are input you turn into TODO, notes and appointments in your calendards.
What I usually want is to be able to have a link to an email that works offline, which open my email client to this particular email. I used thunderlink addon for that because that's the only way to do it, but it sucks.
This link I would be able to paste into my workflow. Apps could use it to integrate a preview of the mail and attachments in the app, cache the mail, ask for notifications about the conversation, get callbacks for events (email deleted, marked as, moved to...) or tell the email client to archive the mail and prevent deletions.
This should work offline (I want to be able to get organized in the plane) and online (APIs => webhooks => cluster of integrated services).
What can we use email to disrupt?
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.
Google Wave is definitely going to change how we do email and instant messaging and also document collaboration.
Oh, whoops, for a second I thought it was last decade.
Oh, whoops, for a second I thought it was last decade.
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.