The fact "email will last forever" is precisely why I believe it is absolutely the best protocol to build automatic services to access and share personal information. I have spoken about it here: http://blog.zorinaq.com/?e=76
Edit: Someone1234: you don't need to wait for companies to support my proposal. It already works today with Gmail: try my live demo on pm33at@gmail.com - it works by leveraging standard auto-responder features. As to the comparison with XKCD 927, it is invalid: my proposal is radically different from anything that currently exists, because it is decentralized while all current personal information sharing platforms are centralized.
Edit: rakoo: yes, XMPP would work too, and would probably be a bit better than SMTP because it is real time. However in practice building something over SMTP has more chances of seeing success (because not everybody uses XMPP, but everybody has email).
Does this have the classic XKCD 927 problem (https://xkcd.com/927/)? Also wasn't this what XML was meant to solve (a single unified standard for interop)?
It could "work" but unless you got at least Microsoft (Exchange server, Hotmail) and Google (Gmail) to sign up then it won't go anywhere (which is largely the issue with all email momentum, Microsoft and Google have no interest so it cannot move forward).
XML is a markup to establish protocol, not a standard by itself (other than the basic syntactical standard). A standard would be something like MathML.
It strikes me that this is all available with XMPP, which also has user@domain address; If we build the correct tools, XMPP can very well supplant SMTP.
Indeed, if XMPP gained enough popularity, it would solve this problem, since it already implements several of these things (personal information, location, etc), AND is extensible.
That sounds like a really cool idea. Have you submitted it here? Got me thinking of pluses and minuses, and ways to bootstrap. Probably somebody would have to put up a free email service that implemented these hidden auto-replies, and maybe submit some pull requests to open-source projects to use it. Maybe Android and iPhone apps for the service that handled the phone info side. Sounds a bit big for an individual side project to me, but maybe it's a startup. It would probably help to get input from a bunch of people/projects on what they'd want for specific use cases.
ufmace: I think writing a browser extension that configures filters + auto-responders on some popular webmails (Gmail, Hotmail, etc) would work best to entice users to adopt the technology. As I explained, many webmails already have all the necessary features to implement the concept (see FAQ 1 at http://blog.zorinaq.com/?e=76). Also, writing a smartphone app to do the same for mobile users would help. There is really no need to launch and run a full-blown webmail service.
I upvoted it, though I feel the pain on getting upvotes and reads on here. I think the last article I wrote got more upvotes on Lobsters than here. You gotta get just the right title at the right time, or it slides off the front page before anybody sees it.
I'm not sure what the best way to get going is. A webmail service dedicated to it would get the best UI, but there's the overhead of getting a webmail service with competitive features to Gmail, Yahoo, etc going and keeping it running. Or you could do a plugin or something, where it might be a challenge to put together a good UI and keep it in sync with Gmail's updates.
I tried emailing that address and didn't get a reply.
But I think that could be a rather cool idea - something like REST over SMTP? Know a single email address, send it a blank email get back and kick off the whole HATEOS process - which actually might more sense for something like this rather than over HTTP.
Ah yes - I was being a bit thick and I hadn't read your blog post at that point.
NB I left a comment there but it didn't format correctly. What I suggested was having the subject line be similar to the first line of an HTTP request i.e. <verb> <path>
I think that a lot of "startups" are using the fantasy of an email-less world as a marketing tactic. I agree, I don't think email is going to disappear. Whether that is a good thing or bad, it's irrelevant
Are you kidding me? In my lifetime, letter mail has had a longer run than email. And you presume from our brief couple years with it that email is never going to be different?
"Impersonal" was only ever a label applied to email by people who didn't yet have access to the Internet, jealous they were being excluded. It's the same people who decried smartphones.
In all areas that matter, email is superior to paper letters. And in all areas that matter, no one has proposed an alternative to email that is superior in a way that cannot be applied to email.
In other words, whatever is wrong about email, can be fixed from within the system. Paper letters had to become email to fix what was wrong with paper letters.
> "Impersonal" was only ever a label applied to email by people who didn't yet have access to the Internet, jealous they were being excluded.
This is factually incorrect. Everone I've ever heard use the term to describe email had internet access and was a regular email user at the time they used the term. I'm sure some people who didn't have email have used the term, and I'm sure some of those people had the motivation you describe, but it is simply not true that it was "only ever" used by people without access to the internet (or, more relevantly, email -- whether on the internet or otherwise, as electronic mail existed on networks besides the internet.)
> In all areas that matter, email is superior to paper letters.
"areas that matter" is a subjective category (and, further, superiority in each of those areas is, generally, subjective as well), it may well be superior to you in each of the areas that matter to you, but those subjective judgements may not hold more generally.
> You say something is factually incorrect based on your own experiences
Well, yes, a categorical claim that something was "only ever" used by people with certain objective features and for a particular reason is factually incorrect if it was ever used by people without those features or for a different reason, so personal experience, while inadequate to establish that it is factually correct, can be quite sufficient to establish that it is factually incorrect.
(You'll note that while I state that the categorical claim is clearly factually incorrect, that it is also quite likely that, while not a categorical truth, there have been at least some dismissals that fit the pattern that it falsely claims is the exclusive pattern for all dismissals of email as "impersonal" -- the error isn't in saying that some people describe email as impersonal for the particular reason described, but in claiming that that is the only reason email has ever been described as "impersonal" by anyone.)
> then comment on subjectivity
The comment on subjectivity was on a different statement (a claim of what is superior and what matters, both of which are inherently subjective) not the categorical fact claim. Recognizing the difference between subjective statements and fact claims is pretty important to being able to participate in a productive discussion of pretty much any topic, IMO.
They countered an assertion that people that a particular statement about the impersonality of email was "only ever" made by people without access to email by asserting the existence of multiple people they had known to make that particular statement about the impersonality about email whilst possessing an email address. Which would make the former statement factually incorrect even if the second poster's experiences were atypical.
There's nothing "subjective" about logically refuting one sweeping general claim with a counterexample from ones own experience, unless we're getting really postmodern about whether people actually recall others referring to email as impersonal whilst possessing email addresses or just perceive that to be the case...
A brief look through Front suggests that it is a specialized ticketing system. I predict that, if successful, it will incorporate more traditional ticketing system features.
> nearly none of the products you mentioned work without an email notification feature.
Not to mention the ability to reply to those emails to add new content to those products. Building around email as a messaging backbone is incredibly powerful.
Is that really the single most important issue? I'd lean towards privacy and authentication as being more important. Team inboxes are not really a mandatory part of email.
The single most important issue with email: Team Inboxes.
Yeah, that's apparently what their product is trying to address:
- Email is not adapted to the enterprise world? Make it more collaborative. Here at Front, we introduce productivity and collaborative features in a standard email client and let companies work as a team on all their incoming emails.
I had a job where I had to deal with a team inbox. It took a bit of work to get it working well. I wasn't in that job terribly long, so I don't know very much about the problem space. But, yes, it was a pain. And I hope they really do have something better to offer.
At my last job we had several shared IMAP mailboxes. The workflow that we used that worked fairly well was to have a sub-folder for each user. When a new mail came in, you'd first move it into your folder, then handle the email.
This worked really well for us, but I think the biggest inbox only had a dozen users.
That's a problem with the end-point, not with the medium. Consider a system like RT[0]; it has no concept of an inbox, yet most (if not all) client interaction is via email. My take is that if you're tempted to set up a shared inbox, don't. Set up a ticketing system instead.
No one mentions portability, but I believe it is a wonderful property of email - I have more than 15 years of email, moved across various servers and clients on various operating systems and it is still available and functional. What other personal communication channel is that resilient to technological change ?
Whitfield Diffie (yes, of Diffie-Hellman), just posted to the IP list an email he pulled up from 1976(!) in response to a crappy article about VA Shiva Ayyadura "inventing" email. I'm sure he's got even older emails, but the fact that he had it, was able to easily find it, and then resend it with a descendant of itself 38 years later is pretty amazing to me!
"
A quick look at my files finds messages from from 1976 that use that format:
29-SEP-76 1935 FTP:CERF at USC-ISI Data Communication Conference/ Sept 1977
Date: 29 SEP 1976 1802-PDT
From: CERF at USC-ISI
Subject: Data Communication Conference/ Sept 1977
To: walker
cc: cerf, wd at SU-AI
22-AUG-76 0857 FTP:LEFAIVRE at RUTGERS-10 MORE ON THE LISP COMPILER
Date: 22 Aug 1976 (Sunday) 1155-Est
From: LEFAIVRE at RUTGERS-10
Subject: MORE ON THE LISP COMPILER
To: DIFFIE at SU-AI
True. But on the other hand, its still (against all reason) too hard to actually do anything with such massive archives unless you really prepare for it .. like you, I have more than 15 years of email collected over the decades, but actually being able to do something productive with it depends on just how much time I want to spend setting up a system that can handle the mbox files of the 80's, the Eudora archives of the 90's, the Mail.app sql-database of the 21st Century, and so on. It has persisted, dear mail-format, but oh what a mess it still is after all these years. I'd kill for a solution that just gives me my own full-text search engine to query/manipulate this archive, without first having to configure stream-plugins to do text conversions and so on. I guess this is one of those cases where I should just set up a dedicated Linux machine (finally, a use for an rPi!) with all the years mails, and promptly set a text search tool on the problem .. trouble is, can I do that without having to train the thing to handle SMTP headers first? Intuitively I'd say "probably this is a done deal out there somewhere" but a part of me still cowers at the idea ..
(And before anyone mentions it: no, google is not my solution. I want to do offline manipulation of decades of mail archives .. not just turn it over to some Entity, Inc. to solve..)
And the reality is that there's a vanishingly small percentage of that archived email that is of any use to you or anyone else. I don't have anything before about 2001 for reasons of isolated proprietary mail systems (e.g. minicomputer-based), disk failures, or just not making the effort to archive. I do have about the next 10 years saved but it's sitting in Outlook on a retired Windows system I keep around for such purposes--but there's no easy way AFAIK to translate it to another format and it's not something I'm inspired to devote great energy to.
You might want to have a look at notmuch (http://notmuchmail.org/). Said abruptly, it's a wrapper on top of Xapian (the search engine) that you feed with your email, after which you can query using mail-related queries:
$ notmuch search from:linus crap
and, most usefully, tag:
$ notmuch tag +rant from:linus crap
Tags work exactly how you would expect them to:
$ notmuch count tag:rant
There are myriads of frontends (even a web-based one [0]) if you want to go further than cli.
You're gonna have to transform everything to maildir or mh though (unless you can somehow iterate over your mails from the formats you have), but I guess that's not too unreasonable to do anyway.
Since I always use IMAP, the local archive format is irrelevant to me - my mail entirely lives on an IMAP server.
I did have to migrate twice: once when switching from Eudora using POP3 to using IMAP, I moved the mail from the local Eudora archive to the IMAP server. Then other times when switching servers - either by moving the maildir or using IMAP synchronization.
I subscribe to the old archiving adage: if it is not spinning, it is dead !
What does that even mean "on" their emails? Actively reading and replying to email is very different from having email open or receiving emails on your phone, etc.
That sounds about right to me if you include both personal and work email time. You might be surprised at the number of people in large organizations that spend seven hours a day actively reading and writing email.
Well, it's not high if you count writing in. Today I spent ~2h just on a single e-mail conversation (few e-mails sent, few received). Writing thoughtfully to another human takes time.
- Email is not sexy? Design beautiful interfaces. Mailbox has managed to make email light, fast, and mobile-friendly. Sparrow was creating the most intuitive and pleasurable mailing experience etc.
I wish the author had not said "etc" at the end. He is obviously very knowledgeable about the topic. A lot of people, even people who spend LOTS of time online (like me) have not tried out every email client out there, and this is a missed opportunity to inform me and impress me with his depth of expertise on the domain his company is involved in.
I am sure I am guilty of this at times, where I either assume "everyone knows what I know" or I realize they don't and I don't want to sound like a braggart or something but I find myself feeling like I have been told "surely, you know all these examples and what they did different/right" and the answer is "No, no I do not -- what did they do??"
It is, however, a horrifically bad protocol. We don't need a new app, but a better protocol for unified mail, IM and audio/video. XMPP is close, but flawed.
Depends on what you mean by "forever." If you mean, say, 30-50 years, even maybe 1000, sure, i'll give you that, but i'm still skeptical, but to suggest that there won't be a better communication tool that comes along to replace the written word from one node to one other, i'd say you're deluded. There is lots of room for improvement.
Agreed. It might seem pedantic to call this article on its use of "forever", but it is not. By setting this in stone you are actually discouraging innovation. Not everyone who promises ground breaking enhancement over email is right, but someone might come up with something.
And if the article's author really meant forever, I can envision a future of effortless communication through PC facilitated "telepathy" or any other sci-fi concept that obviates email. "Eternity, my friend, is a long f[*]ing time"
30-50 years is surely "forever" even in snail mail terms. 1000 years? Wow now we're talking about an era-defining technology for civilization itself! I'm going to go with your lower bound: if email lasts largely unchanged for 30 years, then it will have been the most important application of the internet era.
Well for me, Email is already dead. Of course, dead software still exists, for information can not be destroyed. But, there will be more surveillance. There will be more counter-surveillance tools becoming popular. But Email will not stay on that list. Over the long run, the electronic mail will fall back behind inherently encrypted solutions. At least I hope that.
The concept of email is too fuzzy. Is it SMTP that will last forever? This technology is more like sending postcards that every middleman can read. Certainly a more private alternative will replace it someday, and it should be more spam-proof.
Also email serves many purposes. If it is to be replaced, it will be on a use-case by use-case manner. RSS is a better alternative to one-to-many mailing lists. Forums are a better alternative to many-to-many mailing lists. Etc.
But yes, we should improve what we have until we can replace it.
While SMTP and POP protocols can be transmitted over TLS between hosts, which prevents reading messages along the wire, the email data itself is _not_ encrypted. A compromised SMTP server can easily read and copy any message received or transmitted.
And, even if you use a side-channel to distribute keys between the sender and receiver (to encrypt the data safely), the header absolutely has to be plain-text. Governments and companies scraping email meta-data is already a huge problem.
A protocol closer to Tor would make for much more secure email distribution, but it would also require a complete protocol rewrite. Potential death of email from a back-end point of view at least.
Encrypted SMTP is already in widespread use. Many MTA's already receive and deliver email over secure channels, and email clients (e.g. Outlook) have supported secure channels for a long time.
E-mail is a sufficient way of communication for almost every case - just like traditional, physical mail was 100 years ago. You can send a party invite to your friends, you can send family pictures to your mother, you can discuss a project with your co-worker and you can send an invoice to your customer - all of that using a single application. If you need to contact someone immediately - use IM or phone. Why do we need a seperate tool for every scenario? Sure, they provide some useful stuff, but nothing beats simply opening your e-mail client and typing a message to whoever you want.
I find it interesting to contrast 'forever' with another technology that will last forever 'vinyl records'. I expect there will always be point to point, store and forward communication channels, but those channels have existed for millenia, from travelers who stacked rocks to tell those who came after where the trail was, to people who send compromising photos of themselves across cellular networks. So if we set aside the tautology for a moment, communication channels get morphed into a solution for a particular need, regardless of how well they service that need, and when there is a particularly wide disparity between need and implementation, there is an opportunity to create a better channel.
My current favorite example is Trello as a way of communicating activity status from many to many on many projects. Something email does poorly (but has been used for in the past) and Trello does brilliantly.
But lets look at the points one by one.
#1 everyone has an email address -- sure today they do, and 25 years ago nobody did, and 25 years from now its possible everyone will have a "fooservice" address.
#2 email is flexible -- see my point above, flexing is not the same as serving.
#3 other stuff is great for professional communication but we still use email. -- and before that inter-office memos.
I get that these guys (Front) are invested in email sticking around but I would note that putting an adapter layer in front of it is no more, nor less, efficient than putting an adapter layer in front of TCP/IP or smoke signals or a 45 year old text file transfer protocol, whether or not "email" in the form of SMTP will survive should be irrelevant to Front, the question should be will the need for their service survive.
Why's that? At least within the US I can easily port a number between providers. But if I want to stop using Gmail and switch to Yahoo, I'm screwed. All of my accounts use the gmail address for my login, and most have no visible mechanism for changing it.
I don't change my phone number because it's easy to keep it. I don't change my email because the address is tied to a specific provider and getting everyone to switch to using my new one may be impossible.
gmail and yahoo have not shut down, so i've had no reason to stop receiving mail from those accounts. if i so desire, i can keep renewing a .com domain almost indefinitely for a pittance, and run my own mail for the domain. on the other hand, every 1-2 years when my mobile phone and/or internet connection contract runs out, i reconsider my phone plans. free phone number portability is relatively new thing compared to how old gmail,yahoo mail and hotmail(or running your own mailserver) are.
True, and the cellular wave has made many phone numbers one-to-one rather than one-to-household. But for long form communication, SMS is rather painful, but it would be interesting to see something like Front built on top of it.
Vinyl was physical. As were cassettes, envelopes, postcards etc.
Email has one thing going for it that other platforms similarly didn't offer : It's the first personalised, and therefore recognisable, addressing system for an intangible communications platform that's still largely open (Ex: Unlike twitter et al. which has severely limited means of communication and, more importantly, what I can communicate).
I submit that we don't have an equivalent that's evenly matched and so no basis yet to compare it to. That's not to say there won't be one in the future, but I don't see anything close to matching it today or on the horizon.
It would be interesting to see an alternative to Twitter that is as open as email is. eg: A microblogging system that is built on open standards in a distributed and federated way. Where no-one owns the platform and protocols.
In the beginning of the internet a bunch of open system emerged: Email, IRC, DNS, ... Nowadays it's mostly businesses that launch proprietary solutions to make $$$. What has changed since those early days?
First, money showed up on the Internet. Second, if you don't stand to make a ton of it, you can keep using email, IRC, DNS... No need to launch something else.
Although it's not like new IRC daemons are not written, or new irc networks are not started. It's not dead, it's slowly evolving.
It would be interesting to see an alternative to Twitter that is as open as email is. eg: A microblogging system that is built on open standards in a distributed and federated way. Where no-one owns the platform and protocols.
There has been for years, it's called StatusNet (now GNU Social, apparently) and it's based on the open OStatus protocol. I had my own server federating with the reference instance (Laconi.ca), on which I followed a few users, like Tim Berners-Lee (who mostly cross-posted from Twitter).
I would agree that emails are not suitable for some use cases. Many to many updates on many projects, as you pointed out, is one that email is not a suitable medium. However, I don't see that particular use case as significant by the normal Internet users, rather an enterprise problem. The fact that emails have used for that just shows its robustness and popularity (hey it's good enough and all the people I need to connect with have it, so why not just using it?)
I don't think your analogy with vinyl records app as emails are actually the electronic version of the communication method human have been using for hundreds (if not thousands) of years: mails. People know exactly how to use email and what exactly do they expect from emails:
- to send an email, you need an address
- to receive emails, you need a mail box
- once you hit send, you don't have control on the emails anymore, some thing (or post office workers) have control of it
- you don't expect to get a reply right away, that lowers your expectation of an instant reply
- a lot of emails are replies, which means there is a strong context which is what was said in the previous emails
There are many other good things with email such as the openness, federated and robustness nature of the underlying technologies. However, just from the end users perspectives, it matches perfectly with a communication model that most humans have used and understood for many years, and one that doesn't go away very soon.
Many-to-Many isn't really bad for email. It depends on having servers which intelligently handle the duplication.
Which today, most servers do - they'll hardlink identical mails in mailboxes they control, and fan out those which need to be fanned out.
Email in that sort of medium is just visibly doing the grunt work you need to do for that type of thing over multiple distributed servers. Its no real accident that the Git distributed cloning model pretty closely mirrors this, since it was developed to replace emailing tarballs around for kernel developers.
Email is the ultimate "killer app" you can digitally deliver anything to anyone via email, and many folks use it for all sorts of different processes and purposes. Solutions that claim to displace email don't really displace email -- they displace common use cases that were handled ad hoc using email as a lowest common denominator. Most of these use cases cry out for a more structured solution.
For example, There are 1,000 services that displace emailing pictures to each other. There is probably an order of magnitude more services for managing tasks, approving things, exchanging quick exchanges, or performing any number of other tasks.
But at the end of the day, for the core function of email -- unstructured written communication, email is the king.
Your summary makes me think that the reasons for which huge number of people uses Excel as a database at work are very similar. There is such a thing as not enough flexibility, too much structure.
My opinionated 2¢ on why e-mails will live while many an "e-mail killer" dies mourned by no one.
E-mail is just better way of doing snail-mail, a technology that we had since we first invented writing. One could say that our whole civilization is built on such communication, as one could not conduct business, make a war or govern a country without mail. E-mails is just the same, only faster, and it shares all the benefits with the snail-mail medium. Interestingly, many of those benefits are also shared by... phone.
Why snail-mail, e-mail and phone calls do better than others and will outlast random fads is visible if you look at the structure of the medium. The main features those three forms have that various "e-mail killers" don't are:
- ubiquitous - you can reach anyone...
- distributed and federated - ...anywhere, without caring about whether they subscribe to the same service as you.
The last thing is important. When I send you a snail-mail, I don't know or care how the post office works in your country. When I send you an e-mail, I likely don't know (and again, I don't care) if you pay for your mail server and to whom. When I call you, again, I don't know or care who provides you cellular service. I don't even know what kind of device you use to receive that call.
No single entity owns snail mail, e-mail or the phone network.
On the other hand, with Facebook Messenger you can talk only to Facebook users on Facebook platform. With Asana, I can only talk to other Asana users.
The reasons those services die quickly (when was the last time you ICQd someone? MSNd? or <insert your national IM equivalent that no one uses nowdays anyway>'d?), and the reasons I STRONGLY WISH THEM TO DIE A QUICK DEATH for are greed and hubris. I go to Asana web-page (I don't mean to single them out, apply this to any other similar service) and I can see that idea, "we will replace e-mail, everyone will use our service and we will rule over in-company communication!", floating in the air. No, this will not happen. There will always be people who won't use your service because they don't like your UI or like a competitor more. But what you're trying to do is to throw away freedom of collaboration and interoperability to earn a quick buck. This is damaging to communications, damaging to society, damaging to humanity, and fortunately will disappear quickly into oblivion, like countless other similar startups.
Want to create an "e-mail killer"? Apply some humility. Accept that you will not be The One Gateway to Human Communication; it would be bad for everyone (yourself included) to become one. Just aim for a federated protocol, awesome UI and play nice with others. Sure, success will not be yours only; many others will profit in the same space as you. But embrace that. Wanting to keep everything for yourself is just greed.
Spam is horrible, but filtering seems to work well enough these days. (Which makes me wonder why people are still spamming, but that's a separate post about game theory.)
Filtering doesn't work well enough at all. The fact that you can't be sure if your email was received is a problem. Many companies have over-aggressive spam filters and the recipients sometimes never even see the emails in their spam box - they're either bounced or black-holed. Often this is done by blacklisting IP addresses. When that IP happens to be the mail server of a service provider with many customers, when one of them sends spam, all of them get their emails blocked.
Unreliable delivery is perhaps on of the biggest problems with email. Largely due to faulty spam filtering.
I assume the only reason people boldly claim they will kill email is so they can get VCs excited about their disrupt strategy. It's always about taking out an entire existing industry or system (see Uber).
I think that Maciej Cegłowski got it right in his talk [0] with the concept of investor storytime.
To quote:
"Recall that advertising is when someone pays you to tell your users they'll be happy if they buy a product or service.
Yahoo is an example of a company that runs on advertising. Gawker is a company that runs on advertising.
Investor storytime is when someone pays you to tell them how rich they'll get when you finally put ads on your site.
Pinterest is a site that runs on investor storytime. Most startups run on investor storytime.
Investor storytime is not exactly advertising, but it is related to advertising. Think of it as an advertising future, or perhaps the world's most targeted ad.
Both business models involve persuasion. In one of them, you're asking millions of listeners to hand over a little bit of money. In the other, you're persuading one or two listeners to hand over millions of money."
Most startups indeed do run on investor-storytime.
I've re-read that a few times (and created my own local copy with some simplified and fixed HTML -- it's missing a section heading and has a slew of un-closed anchors). My opinion of it continues to climb. It's well up my list as one of the ten best recently written essays I've read this year. Maciej posts here as "idlewords".
"Investor storytime" is a pretty good insight as well.
I'd add one more thing to ubiquitous, distributed, and federated, and that's free-form.
Quite a few of these email replacement services seem to add a bunch of stuff specific to some particular use-case. It might make it nicer for that particular use-case, but as soon as you need to do something outside of what's anticipated, it grinds to a halt. That means that any organization that uses something like that ends up using 3 or 4 of them, in addition to email. At that point, it's easier to just use email for everything.
Being free-form is also extremely important. I think that the best way to add another "stuff specific to some particular use-case" is just to add additional layers of UI over current form.
Look at how HTML mail is implemented - it's just using underlying text protocol. Ditto for images and other attachments.
I don't see any reason for people not to agree on Markdown formatting, folding Org-mode style headings, rendering [ ] as checkbox that will send a special "I'm ticked" e-mail as a reply when clicked (didn't GitHub start to do something similar with checkhoxes in readme files recently?), etc. Just keep the underlying format simple and gracefully degrading to plain-text for clients who don't support your new feature.
There's also the fact that the email format (something that is specifically not instant or near-instant, is primarily text, and works well in limited bandwidth situations) is well suited to interplanetary messages. I hope we will have that "problem" soon!
I agree with your reasons, but it's interesting to consider that realtime IM is one area that, while there exists a standard, simple, and scalable protocol that's been around for a long time - IRC - it's nowhere near as popular as the proprietary alternatives that followed. IRC usage is declining, and of the people I know, the majority have never heard of it. Yet almost everyone knows about email, AIM, MSN Messenger, and now Skype. What lead to this huge difference? Is it just the triumph of marketing client software, or is there something else?
There's IM the one-to-one communication, and there's IM the multi-user chat. Those are two different concepts, they have their own mechanics of working and are treated differently by society.
But since you brought it up, let's talk about IRC. I'm betting its lack of widespread success is because of the general UX combined with some historical mishaps.
There are things you need to think about when IRCing, like:
that all boil down to a. thinking, b. learning, and c. typing magic incantation into a command prompt. It all gives off this complicated, "techie" vibe.
Remember that the general population can't use a computer [0]. That level of involvement is already too much for people to start using it without a strong reason to do so.
I remember when I started IRCing for the first time. There was another solution, that captured much more users - the web chats. Those ugly, scammy looking Java applets embedded on news portals. They solved all the above problems, i.e. you didn't care about "servers" or "connecting", all channels ("rooms", they were called) were listed on a website and there were no magic modes or something, just users, administrators and kicking (and you as an user had only to grok what "being kicked/banned" means).
And of course you could post rainbows and cat gifs and animated faces made by a crazy artist on drugs.
Chats ultimately mostly died, having gained the (deserved) reputation of scammy and ugly places. Or maybe because society still thinks that talking with random strangers on the Internet is something weird and/or dangerous, I don't know.
Anyway, back to the topic of technological obstacles. At my local Hackerspace, every now and then we invite people to our IRC channel, and sometimes those people are not exactly of computer-competent type. A good way to do this is to point a person to a IRC web frame, that is pre-configured with server and channel names. From his point of view, it's just like entering that old-school chat, except that it looks less crappy. After that person hangs out a bit with us and likes the place, we teach him how to install and configure a best-suited IRC client.
If the IRC is ever to reach popularity again, I think someone needs to build a, pardon the startupy meme, GMail of IRC. That is, an UI that looks good, hides complexity from you. An UI that lets you click through everything, and explains things like "+v", "@", "-c" or "NickServ" in human-readable terms. With icons and colors and simple sentences.
Then there's the marketing angle, but I bet you, if Google ever built an IRC client for massess, we'd see a great resurgence of this protocol
Relay.js is a user friendly IRC client, see http://relayjs.jit.su/ for a demo. Converse.js (https://conversejs.org/) is an XMPP web client that supports XMPP conference rooms. So I'd say we already have good, nice-looking clients and there's room for improving integration on a single service to reach for the masses.
Unfortunately, Relay.js seems to not support colors in IRC, i.e. the "^C3i'm green^C" mIRC encoding. But it looks sweet though, and if one could just skip the "type the server and channel name" (i.e. embed on a community website), it would pretty much mimic the chat experience, only better :).
Anyway, so even if we have examples of pretty, somewhat simple and good enough XMPP/IRC clients, the next step is to get them to the world at large. That pretty much leaves marketing to focus on.
EDIT:
Somebody should bundle a pre-configured IRC server and a webserver hosting Relay.js into a Docker/Sandstorm (https://sandstorm.io/) container set and give it/sell it to companies as "awesome internal collaboration facilitator that improves communication and helps empower the teams to build products for the next generation of the web", or sth.
IRC is for multi-user on-topic chats (eg: support, help channels, or specific topics, etc), while XMPP is more for personal IM. Plus, XMPP is open, standard, and decentralized.
There are a lot of people for whom I have no email address, but whom I can reach at a moment's notice on Facebook. The problem with email is there is no directory, whereas on Facebook it's easy to search for "Friends of Joe named July" or what have you and get in touch with them.
That's like saying that the problem with home addresses is that there is no directory.
Well, that's why you ask the people you wish to interact with the contacts he prefers. Business cards, writing you a quick email, phoning them,... You know, stuff that works for centuries.
What doesn't work at all is spreading your info for anyone to see and having to spend the good part of a day to fend off cold callers.
How do I ask them how they prefer to be contacted if I can't contact them? Imagine an old friend or acquaintance or someone you briefly met at a party. A Facebook friend request is hardly intrusive or difficult to ignore.
FOAF. If you can't reach someone directly, find someone who might be able to. Through their work, friends, organizations, etc. Much of that is fairly easy to work out.
It's how people used to get by. It's called legwork.
The seemingly forever existence of email might be due to the fact that writing an email is the same act as writing a letter. No matter how much technology we have, people will never stop writing letters. The human biological machine chooses the tools that is most familiar and the path of least resistance to achieve its goal. By evolution, we are machines that are designed to be somewhat efficient in the process of achieving our goals. Find the simplest thing that works and use it to get the job done.
As a former Pro DJ that now leads a Unified Communications Startup I find your comparison especially entertaining... and accurate. Vinyl records are still around now although they are more of a novelty item (no one is making real money on them). What has persisted is the analog user interface (especially around DJ'ing). While Email may persist in the future all your contacts and all your communications will be all together in one place. It is ABSURD that when we lose/misplace our physical phones we often simultaneously lose contacts and the ability to make/receive calls & SMS. It is also ridiculous that we can't all have a simple threaded chat log of our communications with all our friends/contacts regardless of if they were calls/SMS/Email etc. Different messaging channels are like different music genre's, many people used to think genre's like rock and hip hop were totally separate because the companies that marketed them worked hard to reinforce this distinction. As tools like the iPod gave the user more choice in how to organize and experience their music they blurred the lines between these genre's. The same thing will happen in messaging. People don't care whether it's a Twitter Message, Email, SMS or call. They just see it as all as communication and no one platform will win the day, it will be a mashup of all of them.
Good points. And I would also observe that email's share of electronic communication is going down with the rise of Facebook and other messaging services.
Sure, email is not perfect, but it is the most flexible communication method the internet has to offer. It is not tight to a single organization, or "owned" by a single company and reasonably portable with an open protocol. Tools will be invented to further optimize the experience, but in essence it will remain the same, just like a telephone call hasn't changed. I will not commit an essential part of my business again, to a single company's closed-sourced product (like for instance MS Office in the past, though OSX being the exception).
I recently started using Mailbox as my personal Email Client again, and I am very impressed in how they "optimized" the experience. It basically converts your emails into task items, with different priorities, in lists etc. When combined with notes, it could make any task / note app obsolete.
Unfortunately it only works with GMail and iCloud, but I hope Dropbox keeps investing in the product.
Sure, email is not perfect, but it is the most flexible communication method the internet has to offer. It is not tight to a single organization, or "owned" by a single company and reasonably portable with an open protocol. Tools will be invented to further optimize the experience, but in essence it will remain the same, just like a telephone call hasn't changed. I will not commit an essential part of my business again, to a single company's closed-sourced product (like for instance MS Office in the past, though OSX being the exception).
I recently started using Mailbox as my personal Email Client again, and I am very impressed in how they "optimized" the experience. It basically converts your emails into task items, with different priorities, in lists etc. When combined with notes, it could make any task / note app obsolete.
Unfortunately it only works with GMail and iCloud, but I hope Dropbox keeps investing in the product.
There are tools to make use of HTTP in all sorts of ways. Curl, Wget, Restful APIs, Sinatra, Grape, etc. Fast, flexible, lightweight.
Email - not so much. Want a local email server? There's Postfix - yuckkk. The overhead of spam - yuckk. The lack of tooling, the lack of configurability, the DNS complexity. The fact that it requires a SAAS to do shared inboxes. Yuck.
What's wrong with Postfix? Sure, configuring it takes a little work, but it's not hard, especially not by comparison with Sendmail, which was the standard everywhere when I began my career.
I didn't even find configuring Postfix to take much work, and I'd never configured a mailserver until a few months ago. Debian's config script autogenerated a basic configuration for me, after prompting with a few questions: receive email for my domain to my unix account, and relay mail only from local or AUTH'd clients. This is the entirety of the manual config I added on top of what Debian produced:
# use maildir instead of mbox
home_mailbox = Maildir/
# reject obvious spam
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated,
reject_unknown_client_hostname,
reject_rbl_client zen.spamhaus.org
It has a very nice manual too, but I have not had to use most of it, because it just works out of the box.
Email is wonderful and terrible. SMTP is pretty simple, and everyone with a static IP can run their own email server. Configuring it requires some study, but it's not too hard.
OTOH creating email clients is hard. I wrote a web server and wanted a webmail client. Basic SMPT messaging is straightforward enough, but MIME is a confusing tangle of protocols and rules that is difficult to understand and implement correctly.
I mostly succeeded but it took a long time. Part of the problem is the complexity means protocols are often violated and my webmail client has to deal with loads of exceptions to protocol rules to work in the real world.
But that's hardly limited to email. Look at http, it has arcane rules too, and some of the common security issues on the net are the result of "sloppily" implementing programs using http. (You know, XSS attacks, SQL injections and so on.)
Email has warts but what doesn't. Certainly email "replacements" will have warts too, especially as they are extended to cover the breadth that email has encompassed.
Forever is a strong word... but I do believe that email will stand still for some good years.
Email will last forever because email has been around since... well... forever. That is one key factor that the article misses: practically everyone is used to email. It's really tough to replace something so well known and widespread.
I guess the desire of doing so it's due to so many people struggling with email. How many times have I peeked people's email client looking to hundreds, heck sometimes thousands, of unread emails.
I always had inbox zero. I won't say that for me email is a joy, but is definitely no struggle. I guess I'm more organized than most people anyway...
Having tried it, and recognizing the degree to which this (at least so far) is happening in the "conscious" mind-space rather than sub-conscious/motor-muscle-memory mind-space, typing is vastly faster. Today. It strikes me as an amazingly hard problem to separate one's "inner monologue" from "thoughts i want to transmit". I suspect an easy cheat would be "imagine typing it out" to create a specific, "physical" demarcation in communication types.
To the point of needing email as soon as you're interfacing with a person outside of your group: I'm seeing more and more options for this built into things like HipChat and Slack (both of which have the concept of 'guest' users).
Disclaimer: I work for a company for whom email is a core part of business.
Email and letter-writing go together, in my mind. Not so much because email is a literal model of letter-writing, but rather because they give you an important abstraction that I think we all need, which is a form of passive communication.
You may get letters which are urgent, and you may get email that is urgent, but the nature of both is that they are hands-off. You don't need to be present to receive mail or email. Well, there is some physical mail that you do need to be present for! -- that being certified mail, some package deliveries, and those represent perhaps a different abstraction. That aside, you have a mailbox to hold mail, and a carrier to deliver it to you. Nobody needs to talk to you, to tell you that happened. You can go and check your mailbox and see what you have at any time.
People who want to "kill" email may dislike the form, the implementation, but the abstraction is useful. It will likely continue to be useful -- I don't foresee a time when it will not be. Email, in some sense, will stick around.
168 comments
[ 4.9 ms ] story [ 135 ms ] threadEdit: Someone1234: you don't need to wait for companies to support my proposal. It already works today with Gmail: try my live demo on pm33at@gmail.com - it works by leveraging standard auto-responder features. As to the comparison with XKCD 927, it is invalid: my proposal is radically different from anything that currently exists, because it is decentralized while all current personal information sharing platforms are centralized.
Edit: rakoo: yes, XMPP would work too, and would probably be a bit better than SMTP because it is real time. However in practice building something over SMTP has more chances of seeing success (because not everybody uses XMPP, but everybody has email).
It could "work" but unless you got at least Microsoft (Exchange server, Hotmail) and Google (Gmail) to sign up then it won't go anywhere (which is largely the issue with all email momentum, Microsoft and Google have no interest so it cannot move forward).
http://sat.goffi.org/features.html
https://news.ycombinator.com/item?id=8263848
I had submitted it twice before, but it got few upvotes: https://news.ycombinator.com/item?id=8157645 and https://news.ycombinator.com/item?id=8030337 It is hard to find a short title that succinctly describes the concept.
ufmace: I think writing a browser extension that configures filters + auto-responders on some popular webmails (Gmail, Hotmail, etc) would work best to entice users to adopt the technology. As I explained, many webmails already have all the necessary features to implement the concept (see FAQ 1 at http://blog.zorinaq.com/?e=76). Also, writing a smartphone app to do the same for mobile users would help. There is really no need to launch and run a full-blown webmail service.
I'm not sure what the best way to get going is. A webmail service dedicated to it would get the best UI, but there's the overhead of getting a webmail service with competitive features to Gmail, Yahoo, etc going and keeping it running. Or you could do a plugin or something, where it might be a challenge to put together a good UI and keep it in sync with Gmail's updates.
But I think that could be a rather cool idea - something like REST over SMTP? Know a single email address, send it a blank email get back and kick off the whole HATEOS process - which actually might more sense for something like this rather than over HTTP.
I do like the blank email + HATEOAS idea.
NB I left a comment there but it didn't format correctly. What I suggested was having the subject line be similar to the first line of an HTTP request i.e. <verb> <path>
Why? So that clients that do not support this protocol will display a normal email to the end-user, instead of something not-so-friendly.
This also means that the body can be free-formed text explaining to the user what this message represents, and how to support this protocol.
Basically the opposite of things like Google Hangouts, iMessage, Skype, Dropbox, iCloud/Google Docs, and many others.
In all areas that matter, email is superior to paper letters. And in all areas that matter, no one has proposed an alternative to email that is superior in a way that cannot be applied to email.
In other words, whatever is wrong about email, can be fixed from within the system. Paper letters had to become email to fix what was wrong with paper letters.
This is factually incorrect. Everone I've ever heard use the term to describe email had internet access and was a regular email user at the time they used the term. I'm sure some people who didn't have email have used the term, and I'm sure some of those people had the motivation you describe, but it is simply not true that it was "only ever" used by people without access to the internet (or, more relevantly, email -- whether on the internet or otherwise, as electronic mail existed on networks besides the internet.)
> In all areas that matter, email is superior to paper letters.
"areas that matter" is a subjective category (and, further, superiority in each of those areas is, generally, subjective as well), it may well be superior to you in each of the areas that matter to you, but those subjective judgements may not hold more generally.
Are you being serious, or kidding? I honestly can't tell.
Well, yes, a categorical claim that something was "only ever" used by people with certain objective features and for a particular reason is factually incorrect if it was ever used by people without those features or for a different reason, so personal experience, while inadequate to establish that it is factually correct, can be quite sufficient to establish that it is factually incorrect.
(You'll note that while I state that the categorical claim is clearly factually incorrect, that it is also quite likely that, while not a categorical truth, there have been at least some dismissals that fit the pattern that it falsely claims is the exclusive pattern for all dismissals of email as "impersonal" -- the error isn't in saying that some people describe email as impersonal for the particular reason described, but in claiming that that is the only reason email has ever been described as "impersonal" by anyone.)
> then comment on subjectivity
The comment on subjectivity was on a different statement (a claim of what is superior and what matters, both of which are inherently subjective) not the categorical fact claim. Recognizing the difference between subjective statements and fact claims is pretty important to being able to participate in a productive discussion of pretty much any topic, IMO.
> Are you being serious, or kidding?
The former.
There's nothing "subjective" about logically refuting one sweeping general claim with a counterexample from ones own experience, unless we're getting really postmodern about whether people actually recall others referring to email as impersonal whilst possessing email addresses or just perceive that to be the case...
</pedantry>
As soon as more than one person works with an inbox, it sucks big time.
But I agree - email will last forever, nearly none of the products you mentioned work without an email notification feature.
Not to mention the ability to reply to those emails to add new content to those products. Building around email as a messaging backbone is incredibly powerful.
Yeah, that's apparently what their product is trying to address:
- Email is not adapted to the enterprise world? Make it more collaborative. Here at Front, we introduce productivity and collaborative features in a standard email client and let companies work as a team on all their incoming emails.
I had a job where I had to deal with a team inbox. It took a bit of work to get it working well. I wasn't in that job terribly long, so I don't know very much about the problem space. But, yes, it was a pain. And I hope they really do have something better to offer.
This worked really well for us, but I think the biggest inbox only had a dozen users.
[0]: http://bestpractical.com/rt/
" A quick look at my files finds messages from from 1976 that use that format:
so I don't see how this can be novel in 1978. "(And before anyone mentions it: no, google is not my solution. I want to do offline manipulation of decades of mail archives .. not just turn it over to some Entity, Inc. to solve..)
The other way to convert it was to forward it to another system.
Among the reasons I've vastly preferred Maildir / mbox mail formats (even allowing for mbox's brokenness).
You're gonna have to transform everything to maildir or mh though (unless you can somehow iterate over your mails from the formats you have), but I guess that's not too unreasonable to do anyway.
[0] https://bitbucket.org/wuzzeb/notmuch-web
I did have to migrate twice: once when switching from Eudora using POP3 to using IMAP, I moved the mail from the local Eudora archive to the IMAP server. Then other times when switching servers - either by moving the maildir or using IMAP synchronization.
I subscribe to the old archiving adage: if it is not spinning, it is dead !
Source? That seems really, really high to me for an average.
I wish the author had not said "etc" at the end. He is obviously very knowledgeable about the topic. A lot of people, even people who spend LOTS of time online (like me) have not tried out every email client out there, and this is a missed opportunity to inform me and impress me with his depth of expertise on the domain his company is involved in.
I am sure I am guilty of this at times, where I either assume "everyone knows what I know" or I realize they don't and I don't want to sound like a braggart or something but I find myself feeling like I have been told "surely, you know all these examples and what they did different/right" and the answer is "No, no I do not -- what did they do??"
Email is broken.
Disagree? I'm sure your response expressing your disagreement won't end up in the spam folder.
There are other things, like awkward and unevenly supported voice and encryption, but those are higher level concerns.
TextSecure's protocol is probably closest to what I'd like to see as a standard.
And if the article's author really meant forever, I can envision a future of effortless communication through PC facilitated "telepathy" or any other sci-fi concept that obviates email. "Eternity, my friend, is a long f[*]ing time"
Also email serves many purposes. If it is to be replaced, it will be on a use-case by use-case manner. RSS is a better alternative to one-to-many mailing lists. Forums are a better alternative to many-to-many mailing lists. Etc.
But yes, we should improve what we have until we can replace it.
A protocol closer to Tor would make for much more secure email distribution, but it would also require a complete protocol rewrite. Potential death of email from a back-end point of view at least.
That's the foreseeable future. Anything beyond that is speculation.
My current favorite example is Trello as a way of communicating activity status from many to many on many projects. Something email does poorly (but has been used for in the past) and Trello does brilliantly.
But lets look at the points one by one.
#1 everyone has an email address -- sure today they do, and 25 years ago nobody did, and 25 years from now its possible everyone will have a "fooservice" address.
#2 email is flexible -- see my point above, flexing is not the same as serving.
#3 other stuff is great for professional communication but we still use email. -- and before that inter-office memos.
I get that these guys (Front) are invested in email sticking around but I would note that putting an adapter layer in front of it is no more, nor less, efficient than putting an adapter layer in front of TCP/IP or smoke signals or a 45 year old text file transfer protocol, whether or not "email" in the form of SMTP will survive should be irrelevant to Front, the question should be will the need for their service survive.
I don't change my phone number because it's easy to keep it. I don't change my email because the address is tied to a specific provider and getting everyone to switch to using my new one may be impossible.
Email has one thing going for it that other platforms similarly didn't offer : It's the first personalised, and therefore recognisable, addressing system for an intangible communications platform that's still largely open (Ex: Unlike twitter et al. which has severely limited means of communication and, more importantly, what I can communicate).
I submit that we don't have an equivalent that's evenly matched and so no basis yet to compare it to. That's not to say there won't be one in the future, but I don't see anything close to matching it today or on the horizon.
In the beginning of the internet a bunch of open system emerged: Email, IRC, DNS, ... Nowadays it's mostly businesses that launch proprietary solutions to make $$$. What has changed since those early days?
Although it's not like new IRC daemons are not written, or new irc networks are not started. It's not dead, it's slowly evolving.
There has been for years, it's called StatusNet (now GNU Social, apparently) and it's based on the open OStatus protocol. I had my own server federating with the reference instance (Laconi.ca), on which I followed a few users, like Tim Berners-Lee (who mostly cross-posted from Twitter).
* https://jappix.com/ Jappix (XMPP)
* http://gnu.io/social/ GNU social (statusnet/pump)
* http://twister.net.co/ Twister (p2p microblogging)
* http://redmatrix.me/&JS=1 Red Matrix
The thing is: noone uses them.
I don't think your analogy with vinyl records app as emails are actually the electronic version of the communication method human have been using for hundreds (if not thousands) of years: mails. People know exactly how to use email and what exactly do they expect from emails: - to send an email, you need an address - to receive emails, you need a mail box - once you hit send, you don't have control on the emails anymore, some thing (or post office workers) have control of it - you don't expect to get a reply right away, that lowers your expectation of an instant reply - a lot of emails are replies, which means there is a strong context which is what was said in the previous emails
There are many other good things with email such as the openness, federated and robustness nature of the underlying technologies. However, just from the end users perspectives, it matches perfectly with a communication model that most humans have used and understood for many years, and one that doesn't go away very soon.
Which today, most servers do - they'll hardlink identical mails in mailboxes they control, and fan out those which need to be fanned out.
Email in that sort of medium is just visibly doing the grunt work you need to do for that type of thing over multiple distributed servers. Its no real accident that the Git distributed cloning model pretty closely mirrors this, since it was developed to replace emailing tarballs around for kernel developers.
Email is the ultimate "killer app" you can digitally deliver anything to anyone via email, and many folks use it for all sorts of different processes and purposes. Solutions that claim to displace email don't really displace email -- they displace common use cases that were handled ad hoc using email as a lowest common denominator. Most of these use cases cry out for a more structured solution.
For example, There are 1,000 services that displace emailing pictures to each other. There is probably an order of magnitude more services for managing tasks, approving things, exchanging quick exchanges, or performing any number of other tasks.
But at the end of the day, for the core function of email -- unstructured written communication, email is the king.
E-mail is just better way of doing snail-mail, a technology that we had since we first invented writing. One could say that our whole civilization is built on such communication, as one could not conduct business, make a war or govern a country without mail. E-mails is just the same, only faster, and it shares all the benefits with the snail-mail medium. Interestingly, many of those benefits are also shared by... phone.
Why snail-mail, e-mail and phone calls do better than others and will outlast random fads is visible if you look at the structure of the medium. The main features those three forms have that various "e-mail killers" don't are:
- ubiquitous - you can reach anyone...
- distributed and federated - ...anywhere, without caring about whether they subscribe to the same service as you.
The last thing is important. When I send you a snail-mail, I don't know or care how the post office works in your country. When I send you an e-mail, I likely don't know (and again, I don't care) if you pay for your mail server and to whom. When I call you, again, I don't know or care who provides you cellular service. I don't even know what kind of device you use to receive that call.
No single entity owns snail mail, e-mail or the phone network.
On the other hand, with Facebook Messenger you can talk only to Facebook users on Facebook platform. With Asana, I can only talk to other Asana users.
The reasons those services die quickly (when was the last time you ICQd someone? MSNd? or <insert your national IM equivalent that no one uses nowdays anyway>'d?), and the reasons I STRONGLY WISH THEM TO DIE A QUICK DEATH for are greed and hubris. I go to Asana web-page (I don't mean to single them out, apply this to any other similar service) and I can see that idea, "we will replace e-mail, everyone will use our service and we will rule over in-company communication!", floating in the air. No, this will not happen. There will always be people who won't use your service because they don't like your UI or like a competitor more. But what you're trying to do is to throw away freedom of collaboration and interoperability to earn a quick buck. This is damaging to communications, damaging to society, damaging to humanity, and fortunately will disappear quickly into oblivion, like countless other similar startups.
Want to create an "e-mail killer"? Apply some humility. Accept that you will not be The One Gateway to Human Communication; it would be bad for everyone (yourself included) to become one. Just aim for a federated protocol, awesome UI and play nice with others. Sure, success will not be yours only; many others will profit in the same space as you. But embrace that. Wanting to keep everything for yourself is just greed.
Spam is horrible, but filtering seems to work well enough these days. (Which makes me wonder why people are still spamming, but that's a separate post about game theory.)
Unreliable delivery is perhaps on of the biggest problems with email. Largely due to faulty spam filtering.
I'm actually surprised, since I actually expected more spam to get through.
To quote:
"Recall that advertising is when someone pays you to tell your users they'll be happy if they buy a product or service.
Yahoo is an example of a company that runs on advertising. Gawker is a company that runs on advertising.
Investor storytime is when someone pays you to tell them how rich they'll get when you finally put ads on your site.
Pinterest is a site that runs on investor storytime. Most startups run on investor storytime.
Investor storytime is not exactly advertising, but it is related to advertising. Think of it as an advertising future, or perhaps the world's most targeted ad.
Both business models involve persuasion. In one of them, you're asking millions of listeners to hand over a little bit of money. In the other, you're persuading one or two listeners to hand over millions of money."
Most startups indeed do run on investor-storytime.
[0] - http://idlewords.com/bt14.htm
"Investor storytime" is a pretty good insight as well.
Quite a few of these email replacement services seem to add a bunch of stuff specific to some particular use-case. It might make it nicer for that particular use-case, but as soon as you need to do something outside of what's anticipated, it grinds to a halt. That means that any organization that uses something like that ends up using 3 or 4 of them, in addition to email. At that point, it's easier to just use email for everything.
Yes! A thousand times yes!
Being free-form is also extremely important. I think that the best way to add another "stuff specific to some particular use-case" is just to add additional layers of UI over current form.
Look at how HTML mail is implemented - it's just using underlying text protocol. Ditto for images and other attachments.
I don't see any reason for people not to agree on Markdown formatting, folding Org-mode style headings, rendering [ ] as checkbox that will send a special "I'm ticked" e-mail as a reply when clicked (didn't GitHub start to do something similar with checkhoxes in readme files recently?), etc. Just keep the underlying format simple and gracefully degrading to plain-text for clients who don't support your new feature.
But since you brought it up, let's talk about IRC. I'm betting its lack of widespread success is because of the general UX combined with some historical mishaps.
There are things you need to think about when IRCing, like:
that all boil down to a. thinking, b. learning, and c. typing magic incantation into a command prompt. It all gives off this complicated, "techie" vibe.Remember that the general population can't use a computer [0]. That level of involvement is already too much for people to start using it without a strong reason to do so.
I remember when I started IRCing for the first time. There was another solution, that captured much more users - the web chats. Those ugly, scammy looking Java applets embedded on news portals. They solved all the above problems, i.e. you didn't care about "servers" or "connecting", all channels ("rooms", they were called) were listed on a website and there were no magic modes or something, just users, administrators and kicking (and you as an user had only to grok what "being kicked/banned" means).
And of course you could post rainbows and cat gifs and animated faces made by a crazy artist on drugs.
Chats ultimately mostly died, having gained the (deserved) reputation of scammy and ugly places. Or maybe because society still thinks that talking with random strangers on the Internet is something weird and/or dangerous, I don't know.
Anyway, back to the topic of technological obstacles. At my local Hackerspace, every now and then we invite people to our IRC channel, and sometimes those people are not exactly of computer-competent type. A good way to do this is to point a person to a IRC web frame, that is pre-configured with server and channel names. From his point of view, it's just like entering that old-school chat, except that it looks less crappy. After that person hangs out a bit with us and likes the place, we teach him how to install and configure a best-suited IRC client.
If the IRC is ever to reach popularity again, I think someone needs to build a, pardon the startupy meme, GMail of IRC. That is, an UI that looks good, hides complexity from you. An UI that lets you click through everything, and explains things like "+v", "@", "-c" or "NickServ" in human-readable terms. With icons and colors and simple sentences.
Then there's the marketing angle, but I bet you, if Google ever built an IRC client for massess, we'd see a great resurgence of this protocol
[0] - http://coding2learn.org/blog/2013/07/29/kids-cant-use-comput...
Unfortunately, Relay.js seems to not support colors in IRC, i.e. the "^C3i'm green^C" mIRC encoding. But it looks sweet though, and if one could just skip the "type the server and channel name" (i.e. embed on a community website), it would pretty much mimic the chat experience, only better :).
Anyway, so even if we have examples of pretty, somewhat simple and good enough XMPP/IRC clients, the next step is to get them to the world at large. That pretty much leaves marketing to focus on.
EDIT:
Somebody should bundle a pre-configured IRC server and a webserver hosting Relay.js into a Docker/Sandstorm (https://sandstorm.io/) container set and give it/sell it to companies as "awesome internal collaboration facilitator that improves communication and helps empower the teams to build products for the next generation of the web", or sth.
That's like saying that the problem with home addresses is that there is no directory.
Well, that's why you ask the people you wish to interact with the contacts he prefers. Business cards, writing you a quick email, phoning them,... You know, stuff that works for centuries.
What doesn't work at all is spreading your info for anyone to see and having to spend the good part of a day to fend off cold callers.
It's how people used to get by. It's called legwork.
Now, what are the problems with e-mail that it's inevitable successor will fix other than, "it's old" ?
Those who complain about email tend to focus on arguing for solutions to problems that don't exist.
I recently started using Mailbox as my personal Email Client again, and I am very impressed in how they "optimized" the experience. It basically converts your emails into task items, with different priorities, in lists etc. When combined with notes, it could make any task / note app obsolete.
Unfortunately it only works with GMail and iCloud, but I hope Dropbox keeps investing in the product.
I recently started using Mailbox as my personal Email Client again, and I am very impressed in how they "optimized" the experience. It basically converts your emails into task items, with different priorities, in lists etc. When combined with notes, it could make any task / note app obsolete.
Unfortunately it only works with GMail and iCloud, but I hope Dropbox keeps investing in the product.
Email - not so much. Want a local email server? There's Postfix - yuckkk. The overhead of spam - yuckk. The lack of tooling, the lack of configurability, the DNS complexity. The fact that it requires a SAAS to do shared inboxes. Yuck.
Email could be so much better.
OTOH creating email clients is hard. I wrote a web server and wanted a webmail client. Basic SMPT messaging is straightforward enough, but MIME is a confusing tangle of protocols and rules that is difficult to understand and implement correctly.
I mostly succeeded but it took a long time. Part of the problem is the complexity means protocols are often violated and my webmail client has to deal with loads of exceptions to protocol rules to work in the real world.
But that's hardly limited to email. Look at http, it has arcane rules too, and some of the common security issues on the net are the result of "sloppily" implementing programs using http. (You know, XSS attacks, SQL injections and so on.)
Email has warts but what doesn't. Certainly email "replacements" will have warts too, especially as they are extended to cover the breadth that email has encompassed.
Email will last forever because email has been around since... well... forever. That is one key factor that the article misses: practically everyone is used to email. It's really tough to replace something so well known and widespread.
I guess the desire of doing so it's due to so many people struggling with email. How many times have I peeked people's email client looking to hundreds, heck sometimes thousands, of unread emails.
I always had inbox zero. I won't say that for me email is a joy, but is definitely no struggle. I guess I'm more organized than most people anyway...
[0] - http://emotiv.com/
- Workers check their emails an average of 74 times a day"
LOL
Email and letter-writing go together, in my mind. Not so much because email is a literal model of letter-writing, but rather because they give you an important abstraction that I think we all need, which is a form of passive communication.
You may get letters which are urgent, and you may get email that is urgent, but the nature of both is that they are hands-off. You don't need to be present to receive mail or email. Well, there is some physical mail that you do need to be present for! -- that being certified mail, some package deliveries, and those represent perhaps a different abstraction. That aside, you have a mailbox to hold mail, and a carrier to deliver it to you. Nobody needs to talk to you, to tell you that happened. You can go and check your mailbox and see what you have at any time.
People who want to "kill" email may dislike the form, the implementation, but the abstraction is useful. It will likely continue to be useful -- I don't foresee a time when it will not be. Email, in some sense, will stick around.