Email is not broken: It’s a framework, not an application
blog.killtheradio.net
blog.killtheradio.net
I am fed up with posts telling me email is broken and a new disruptive tech will be the cure. Email is an open protocol, decentralized, providing optional security.
Shortcomings—or rather call them additional requirements—can be solved with tools keeping email focussed on async text-based communication. Want to send large files? Dropbox. Want more automation? Improve the client side and/or write scripts. Want less spam? Don't distribute your address or sign-up everywhere.
If you don't like your inbox being a todo-list you should change something—maybe your job, profession or your work environment but it's definitely not email. I have got rarely todos in my inbox.
For me, email is—if you mind a set of rules—an efficient way of communication which is documented. You can easily and asynchronously discuss and agree on topics in a transparent manner with one or more participants, again: with an open and decentralized technology, no middleman anywhere. Sometimes obviously it's better to meet folks face to face.
Now tell me, which tool can do this? What do you want to improve?
This whole email is broken thing is just done for the sake of getting attention, making a lame conference presentation "disruptive" or getting some crappy todo app funded.
Your posts reminds me of someone arguing to keep the oral tradition going instead of switching to writing.
I am not saying anyone has suggested anything close to the equivalent of writing, but there is definitely a fundamental problem with email that can't just be solved by a couple of perl scripts and rules. I would also assume one's career choice is a premise for making better tools and protocols - anything else seems kind of backwards. If the president was forced to work in a public market space, would you tell him to change career if he remarked on how he couldn't get anything done?
There is a difference in saying email should be killed forever and that it should be replaced by something else for certain usages, just as twitter and Facebook replaced portions of email. Incidentally though, such a replace could likely render email useless for many people.
So we should not use email as a TODO list, but keep a separate TODO list. Email is not broken, it's just the wrong tool for keeping TODO lists.
I would never have thought of (mis)using email for a TODO list, and I'm astonished to read from various famous people (not just pg) that they're seriously doing that. Maybe this is a typical mistake of Internet beginners, but why are so many experienced and very busy people doing such a huge organizational mistake, every day?
There are lots of tools for keeping a TODO list. For my personal purposes, a plain text file works flawlessly. [1] Bigger organizations use various forms of issue trackers, or use a simple Wiki to simulate an issue tracker.
This is a common problem for busy people and has no obvious solution. One way we try to tackle hard problems is by identifying them, and then having open discussion.
> or use a simple Wiki to simulate an issue tracker.
> For my personal purposes, a plain text file works
> flawlessly.
My current solution is multi-layered, and starts with a text file. But it's not the simple problem that you make it out to be.
The real cause lies in people with deficits in time management, organisational skills and leadership.
If you have too many projects/threads going on with too many people time to change: do fewer projects, focus, delegate, give people goals rather than nitty-gritty todos, basically stop micro-managing, find talented peers and trust them.
Technologies lend themselves to particular use and misuse, and when we see a repeating patterns of abuse, it's reasonable to focus on the technology and talk about what we can do differently.
The original post is talking about email as a series of protocols and ignoring the culture of email as we use it in day-to-day use. It's a nerdy rant that dismisses a problem space by forcing a new definition on the language, rather than addressing the problems that people suffer. The chap I relied to continues the tone by insulting people who are dealing with the queue.
Email is the monitoring messages that clog up my inbox. It's the reasonable expectation of response that happens when somebody sends me an email, unlike with my phone where I leave voicemail turned off or a colleague can take a call and I can know that ownership has shifted. Email is the ease with which a difficult-to-understand message is sent and the exhaustion created by comprehending it. It's the poor integration with task management. It's the awkwardness around tracking ownership of an issue that's sent to a group list. It's spam. It's the compromises you make to avoid spam. It's how awkward it is to implement IMAP, and the multiple eccentricities of different IMAP servers, and how woeful POP is. It's Lotus Notes and Exchange, and being forced to use them.
The asynchronous messaging that email provides is it's killer feature that would need to exist for any of the features (todo,task management,calendering...) that you mention would need to work well. But the underlying mechanism of email is still working fine and I don't think that should change.
I agree with the article, the client is where this should go with maybe some thing similar to the W3C and Browser vendors (This isn't perfect but it works) agreeing to protocols.
This is the most important advice, I think. Although delegating, etc. is very important, too.
Automatisation is not the last word for every human activities. Many people are struggling to find a job. Many could do this kind of task efficiently, and even enjoy it.
Maybe I have a different point of view because I live in China, where labor is cheaper, but for instance here if you have a kid and don't wish to change 100% of his diapers, you can just pay someone to do so, it is cheap enough and many people are happy to do this for you (it is often better paid and always safer than working in iPad factories).
"Externalizing" some tasks to other people also means you have a life with more and deeper human contacts. Surely, these human being must be handled much more carefully than a "web service", you have to smile to them and consider their problems. Sometime you have to do compromise and accept a less than perfect outcome. Sometime you have to manage these people that work for you. But this is life.
Is it just that you're communicating with too many people? Do most of the emails require action, or are some of them things you don't even want to read?
And what is that problem? Yeah, email makes a poor to-do list, but if everyone around you is eating soup out of top hats, then you need to rethink soup bowls, not top hats. Tinkering with email doesn't help you make a better to-do list.
Around 1999 or so I noticed someone trying to send spam to every common name on my mail server. I had never given out my email address and yet here I was getting spam just because I had a server. Even if I heavily obfuscate my email address on my website such as with this hack http://icefox.github.com/js_email_link_hack/ I would still get spam because this attack vector.
Email is a good asynchronous messaging protocol, it's not a great one though. I'd say authentication would be a requirement for such a protocol to be great. I think the next logical step of content protection (encryption) is free if you have authentication and most would want it too. You also don't know if a message has been received, ignored, or blocked by a spam filter.
It's good, it does manage to work and deliver billions of messages a day. And it works pretty well. It's infuriating when it doesn't though.
Anyone who claims "email is a bad TODO list" is an email problem is missing the forest for the trees. This isn't an email problem. It's a problem inherit in any communication medium.
If you sit in an IRC channel that can become a TODO list too. For snail mail, the coffee table you throw everything onto is a TODO list. For people who receive a lot of phone calls, their voicemail is a TODO list.
I can imagine email software that does exciting things with JSON data in emails, but I wouldn't alter the underlying protocol.
Nethertheless, I welcome that seemingly a lot do not blindly follow this BS.
Only partially related, but I'm sick of people coming up with more, 'better' ways to communicate which are then embraced by a subset of my friends and colleagues. My email arrives on my phone, on my laptop, on my (and any) PC, in an easy to read, indexable, exportable and simple format, wherever I am in the world, in near real time. I have had the same email address for ~ 12 years and with Google's spam filter I get zero spam. I actively manage mailing list subscriptions and have no problems there either.
Seriously, for people asking where their jet pack is - take a step back and think about all of that.
It's infuriating for me that my friends choose to use Facebook, Twitter DMs, any number of 'groundbreaking' proprietary messaging apps and a million other message transports (don't get me started on iMessage). Email is a message, in text format (with optional binary attachments), between a number of people. Nothing more, nothing less.
The world has bigger problems to solve.
Generally yes, assuming everything between you and the recipient is properly configured, but it's not guaranteed. It's possible to send an email had it just disappears. No bounce, no delivery. It doesn't happen often, and as far as I know it's never happened to me, but there's nothing in the protocol that guarantees delivery or guarantees notification of delivery failure.
That said, this is not a big enough problem to require a new protocol or a change to the existing protocol, or in any other way be worth "fixing." If you are building something that requires guaranteed delivery of messages, don't build it on SMTP.
While it's possible for a mail to just disappear (or more often, automatically be sorted into a spam folder) the protocol is designed to be quite robust in how responsibilities for delivery are passed on to servers delivering the message.
Quite a lot of spam isn't my e-mail address on mailing lists or sign-ups, it is people I know getting a virus or downloading an app that uploads their address book. I have an e-mail only used with friends that gets an amazing amount of spam (not a common name).
E-mail has problems because it isn't one thing. E-Mail is SMTP, IMAP, POP3, and whatever weird thing Exchange is doing.
I really don't see a replacement since we seem to be in the "closed system" stage of social media much like we once were in the same stage with e-mail (e.g. MCI could not send e-mail to AOL). Variants of IM might have worked but the open versions really didn't make it to everyone.
(sorry, I have nothing against that when joking with friends or reading some not so serious post, but it does not fit to a commentary about email)
Yes, I probably do have the sense of humor of a 12-year-old, but that's immaterial.
Or is that you don't agree the author should be allowed to swear in his blog?
Or perhaps you don't agree that blue material is fitting for HN?
For certain, the blog in question would be better received by some if it were written differently, but I don't know what that has to do with the conversation here. (The counterpoint is likely true as well.)
I'm trying to determine what about "Diff'rent strokes for diff'rent folks" the parent could choose to disagree with.
no offence but I feel like replying to a troll, and I know I shouldn't :(
I'm not sure what he disagrees with, or where he intends to enforce this 'polite etiquette', or why someone posting an entry on their blog should be beholden to his set of rules.
It's a genuine question to slake my own curiosity. I am by no means the arbiter of all things tactful, but I am curious where he expects the boundaries to be drawn. I am also extremely eager to hear how one can disagree with the idea of "Diff'rent strokes", as I would posit it as the hallmark of tolerance.
If it is our idea that we should promote civility above tolerance, or above intellectual discourse, then I'd like to hear more insight on that.
Also, not that it's my place to say, but one of my favorite guides for posting on HN is to 'assume good faith'. If you feel like you're responding to a troll, then you shouldn't respond, or you're just feeding worse onto bad. If you're responding, then you should assume good faith, and not make responses like "I'm feeding the trolls".
I don't know what could have been trollish about my question, but I also don't see any particular added value in your comment except to make doubly sure that I actually intended to ask the question I already asked.
Also, your stance might be unfortunate if someone ever shouts at you, "Fuck me, there's a tiger, run!"
But I was being an arse for picking at that in the first place anyway, I just thought that your views on avoiding swearing were a bit over the top and not entirely realistic.
Many professional environments cope fine with quite a blue tinge to their speech, possibly because having to watch your tongue all the time can be a negative in places that require rapid communication with the full range of emphasis.
However, I still don't think it is appropriate to swear in a written communication.
Can anyone offer some links to recent/current projects that want to "fix" email by changing the protocol?
I haven't been following this so closely, but the articles I have read seem to position these proposals as changes to e-mail as a system, if not as a protocol. I leave thinking the authors want to do something radical, to alter something longstanding, to go up against giant, ingrained players and conventions.
I don't think this post would have happened if we were instead hearing more about "new ways to use e-mail," or "adding functionality to an email client." I think the narrative is more like, as others in the thread have referenced, PG's frighteningly ambitious ideas, more like visionaries who are daring to challenge something so established.
Making a new email client that has some extra features is one thing. Changing email forever is another. I think that's what the post is reacting to.
Edit: and, anyway, I think sharpening the discussion by invoking the difference between the client and the protocol is useful, and hopefully will make future conversations about this more clear.
I think PG is in the minority when he considers a conversation over email a "degenerate case" of a TODO list item. A public-writeable personal todo list application is separate from my email client, whether it uses the email protocol to send todo items, or a new protocol to send todo items, or http to put todo items on a centralized database, etc.
I was reading those posts earlier, thinking the same: there is no point in burdening email with constructing 'todo' lists for named senders because my Opera mail client has been doing this successfully and more flexibly with filters for years.
Also, the thought of receiving potentially important emails which can only be read by, say, 'MS word-receiver 2012, v.3.2' fills me with forboding.
So? Is that bad? Everyone has their own way of expressing. Some herein declare that electronic mail is not flawed. Some say that email is not broken. Some just say that email doesn't need dick-sucking.
No they are not. Some are more * preferred * by you than others. Personally I find such metaphor to be engaging & expressive. I love @holman 's writing for same reason. But that doesn't mean one is better over the other.
Writing style is form of art & expression. The quality of an art piece is determined by how well it is expressed and formal technicalities. So as long as his expression is in place, and grammar is sound - it's good art.
To 99.99% of people who use email, Paul is correct: "Email is not a messaging protocol. It's a todo list. Or rather, my inbox is a todo list, and email is the way things get onto it." When people say "email", they almost always mean their email client.
Failure to account for the common usage of the word and demand that people use the word email only to mean the protocol is short sighted, results only in the angst found in this article, and solves nothing. Life is too short to be so angst-filled over the use of one word.
I don't agree with this, in fact I feel this projecting the email power user's use of email onto everyone. At the end of the day, I think most people just want to email each other a message or a small file or pics of their kids or the latest dumb chain email. I do use my email as a todo list personally I write those elswhere, I do send myself links through email but I've configure Gmail to recognize that and put them in my bookmark label.
I also agree with the post, email does what it's meant to do well and you can build clients to do all the features you are asking for.
Half of these are not to-do items in a sense other than "please read this text". They don't even want a reply.
* The political call to action is an annoyance; it wants me to sign a petition against CISPA. I plan to write my congress people directly instead. I don't know how I got subscribed to these, but writing this comment reminded me to unsubscribe.
* I don't want to read any of the four newsletters. I might want to read them some day, and ideally, they'd be filtered in to a "newsletters" folder and not show up as "new mail" when they come in.
* The account statement is something I want to have but not act on. It shouldn't trigger a "new mail" alert either.
* I have no desire to apply for the jobs. I'm kind of curious as to where these people got my email address, as they appear to be actual employers and not recruiters.
* I might go to the meetup.
* I wrote a reply to my friend, agreeing to host her website and telling her what she needs to do to make that happen.
How do you propose to improve my experience?
This type of writing sure gets people excited and attracts many readers but it's a quite destructive way to think of our world. Just because something has certain annoying problems or has maybe become boring and mundane does not mean that the only way to make it better is to completely reconstruct it. Most "It's broken" essays usually come with a dangerous degree of hubris and presuppose that in order to make things better, the offending industry needs full destruction before it can be rebuilt and renewed in the image of writer's glorious new vision (often times this vision is not even presented - it seems that something being "broken" implies that there is a better and completely different way of doing it). Lessons learned doing things the old way become meaningless or at least decline in value because, well it's broken.. we didn't really learn that much right?
I agree that sometimes a complete re-framing is needed to get on the (more) correct path towards making something better or at least just to allow yourself to "think outside of the box". But going on a deconstruction campaign of everything that's served us reasonably well thus far is another box which you can easily trap yourself into.
However, email is broken. Email is inherently insecure, unauthenticated and wide open to abuse. There is no way of knowing that an email from me is really from me and wouldn't it be better if SPAM could never get onto the network in the first place?
The problem with SPAM is that what some may consider to be a 'fascinating circular' will be perceived by others as SPAM.
SPAM is often in the eye of the beholder.
GPG is not user friendly. Remember, the public are stupid.
Doesn't work unless you teach people about security, which is difficult. We have padlocks next to URLs but it's amazing how many people are still willing to send CC info over HTTP.
> SPAM is often in the eye of the beholder.
There's a lot of grey area, but when a particular string has a 99% unread/deleted rate, you can make statistical inferences. An enormous percentage of email falls into this category, and it's why "spam filters" exist and generally do a good job.
GPG has email clients and key management clients (e.g. seahorse) which make it increasingly user friendly.
> Doesn't work unless you teach people about security, which is difficult.
Simple, transparent security is hard. But this is again a UI problem, not a failing of email.
Think about this for a second: let's say Google decided that it was going to transparently PGP-sign all GMail users' emails. Now GMail knows that any message with a from address that ends in @gmail.com but without a valid PGP signature is fraudulent.
Now let's say Yahoo wants to adopt this too. So we add some syntax to SPF that advertises, "any mail coming from this domain must be PGP signed." And another field that points to a public key server. So then all other SMTP servers (or even end-user mail clients, if they want), can auto-reject mail based on this criterion.
Sure, this leaves out some details, like people sending mail from an @gmail.com address using their own SMTP server via a thick mail client that doesn't support PGP (or requires complicated setup to do it properly, like most do). But it's a (hopefully) interesting idea that might work with some modifications.
This has nothing to do with email per se, nothing about its successes or failings. It's just building an easier-to-use distributed authentication system that mail recipients can use.
Paypal and eBay do this. Gmail filters out any DKIM-fail or SPF-fail mails purporting to be from @paypal.com and sends it to spam, with 100% accuracy. Gmail also puts the little 'key' icon next to the sender name, but that's not really important, the point is that any and all fraudulent emails are filtered out with unerring accuracy.
Thus, we don't need to use PGP or whatever, which needs to be handled at the client level. DKIM + DMARC is already here and working at the server level. You don't need to wait for your favourite email client to adopt DMARC.
Yes, if people send emails without going through that SMTP server etc etc.. that's a problem, but also solvable/solved.
So what about the technical problems? The crappy security, the poor error messages, that the senders email gets dumped straight to spam without any notification? What about crappy email threading that requires people to send the entire post back in the reply? That if a normal person wants to send emails themselves it's a colossal undertaking that's better farmed out?
Say it's not a todo app, sure. But don't pretend that there's not any problems with it.
All these are issues with email clients and not email itself.
You want security? Encrypt your emails before sending them.
Poor error messages? The computer understands the error code its getting. It's your client that's not showing you a layman understandable error message.
Sender's email dumped straight to spam without notification? Duh, hello, it was sent to Spam because your client classified it as spam (and more often than not, that classification was right). Do you want to get a notification for every email that lands up in your spam folder?
Email, threading works pretty fine in gmail, so I suppose that again is a client problem.
And normal people send and recieve emails daily. Very rarely does a 'normal person' send bulk emails, and if you wish to frequently send bulk emails and not get caught up in spam filters, then you will have to work a bit towards it. However, again this is not a problem with email. It's a problem with the spam filters of service providers.
What I am trying to say here is that the author's point is simply that email is very good at what it does. The issues with email are all in the way the email is handled, and not in email as a technology itself.
As the most basic form of communication, email is the place to look to solve peoples problems. If we are using email to do or accomplish something, that is an opportunity for a startup to build a new app that simplifies that specific form of communication, and solve the pain of using email which was clearly never meant for or is just a bandaid for that need.
Just look at your inbox and what you use it for and ask yourself, "Does this belong here? Could this be done better? If the Answer is Yes, Great, Go build a new startup!"
Before we had social bookmarking, we mass emailed our friends.
The way of the world and evolution is things diverge. They break off into smaller, hyper-focused products and services. This is how new categories are created and new brands succeed. This is a LAW OF NATURE, a LAW OF EVOLUTION and a LAW OF BRANDING.
Want to build something great and amazing, something frighteningly ambitious, look at your inbox and FIX EMAIL!!!
I think improving email lies before the client. Email is just a message container and apps generally throw a load of different content into that container, events, to-do's, photos etc.
Some of this stuff should never arrive in my inbox. A to-do email should automatically go to my to-do list, an event should automatically go to my calendar, photos should automatically go to iPhoto (or whatever).
Separately to that I can choose how I'm notified about that content.
For example, for all the marketing emails, I'd much prefer to have a Flipboard type app on my mac that receives all of those messages so that they never arrive in my inbox.
So no, email is not broken, but we haven't kept up with ways to manage the growing number of correspondence email is handling. I think the solution lies on the server where mail is sorted into types i.e. if you have that Flipboard for Marketing app, you get those marketing messages otherwise you don't.
Of course, considering almost everyone is using webapps for that type of stuff nowadays, you'd probably need an Akonadi-on-the-cloud solution, POSTing stuff to each webapp as messages come in.
I was thinking more that I'd never actually get these messages via email, that on the mail server, these messages would be interpreted and assigned to whatever app/protocol is relevant. A bit like Tripit do with bookings email.
Look forward to see more from your app!
Full disclosure, I do Community Management/Developer Relations for Context.IO.
The protocol is SMTP,POP3, and IMAP. The data format is something defined through various RFCs and proprietary convenience. The use cases differ from corporate Outlook via Exchange server to people typing text into webforms.
Except when you DON'T. Except when the mail server is broken, except when the error message you get is ENTIRELY CRYPTIC.
Email works. That's it. It doesn't work WELL, It just works. That's why it needs to be fixed.
> But sometimes I just want to send a fucking message, not “make a TODO.” Boom, I just “broke” the new email.
Though I think you're fairly right about this one - you're also wrong. You're making whoever you're messaging a TODO. "Read This" Email has become a TODO list, you can't fix that - not without a new mail protocol that takes that into account and separates the todos from the messages. Certainly a client could do this but a client can never ever be smart enough to get it right all the time.
Separating TODOs from messages reliably can be done using MIME. You do not need a new protocol for that, just define a format and give it a custom MIME type.
X-Todo-Item: true
But why then do i love getting an sms? Where's the difference? The speed? The quality? The simplicity? Somewhere, email has gone wrong.
A simple answer could be that've just been giving out my email to too many services, but honestly, that's what every email user does, and this should be assumed by the developers. It could be that it's just the clients that are broken, but then fix the clients!
Most people I know think modern communication is holy and you should check you're email and text messages multiple times a day and always answer as soon as possible.
I check my email personal email once a day (often don't read any email in the weekend) and this sometimes pisses people off. It sometimes feels like I should constantly be on my guard because people have send me something important (which it almost never is).
I would love it if we could go back to the time when you could only answer the phone when you are at home. Or the time when it was acceptable to wait two days to reply to email.
But i guess this is a bit of topic because the original message was talking about the technical part of email :P
I wonder how large percentage of messages are dropped silently by services like GMail as a spam prevention measure. I bet it's non-zero.
> It’s simple.
How many email related RFCs are out there? And how many additional non-standardized common practices there are? How many pitfalls imposed by common legacy software? Email is far from being 'simple' imho.
Yes, a lot of stuff can be done at the client. But email protocol stack is still very ugly as a whole, especially if you need to reliably inter-operate with the rest of the net.
Nobody forces you to use GMail. There are other mailservers with a much more sane behavior. For example, the mail server I use either accepts a mail, or doesn't accept it (when it looks like spam). It might be possible that a certain percentage of mails is misclassified, but in that cases the sender receives a confirmation.
edit: I might add that spam backscatter is a significant issue (which stems from fundamental problems in email), and thus not sending bounce messages is fairly sane too.
If your server accepts the email first, then scans it, and then decides it is spam, it's too late. Then it has only the choice between ignoring and backscatter, because it can't reliably inform the real sender - the TCP/IP connection is already closed and the email's sender is almost certainly forged.
However, if your server scans the email during the SMTP transfer, and rejects it with a clean error code, the sender gets a clean error message and its the sender who is responsible to inform the client.
Note that there's another downside of this approach which is why you don't find this early-reject very often in the wild: The receipient has no chance to get the email, not even by scanning their spam folder. So the sender has to understand the error message and to send a "less spammy" email, or he can't get in contact to the receipient at all. For some professions, this might be a no-go, as this means missing potential customers just because they use a bad email client which sends spammy-looking emails.
However, if you don't have this "type" of customers, early-rejecting on SMTP level is a perfect solution. We're using this configuration for years on our mail servers, it works pretty well and we've never, ever had to send backscatters. Yet every sender whose email was classified as spam has been correctly notified about this issue.
If you allow me to pick an interesting remark from this post: I think the idea of embedding instructions in the payload of an email is an interesting one. For instance an email could contain text and a link to a Pivotal Tracker story while at the same time it could contain a JSON payload which tells my augmented email client to render the story and allow me to interact with it. The post makes a good point in that email as a protocol is not broken but that the problem lies with today's email clients.
There are two reasons that email and SMS are not broken, and the author of this article points them out: asynchronous communication, and no single entity controlling the entire ecosystem. The value of knowing you can reach anyone, anywhere, anytime is worth a lot more in most use cases than some extra features appealing to one or two very specific use cases.
The SMS improvement is not an improvement to the protocol, but to the tools and is a great example of what people mean when they say email can be improved.
If my mother in law wants to send a gigantic PowerPoint deck of "Our Grand Canyon Vacation.ppt", why should she sign up for a separate service to do so?
There is opportunity to improve the tools which have been and always will be known as email.
All of these users fall into one umbrella category, however: a group of at least two people, at least one of whom needs to say something to another person. If I need to say something now to a friend, I use SMS ten times out of ten. Why? Because I know, without a doubt, that if I send an SMS, it is going to be read by that person regardless of device, software, etc. A centralized protocol is required to tie together disparate software. The 140 byte limit is annoying. But what happens when technology catches up to human length requirements, and it is extended to 400 or 1000 characters? Then you are going to care about length limits even less.
The author's point is that email as a concept and prototype is not broken and is functioning exactly as it should be, which is why it is the preferred communication medium for most people despite decades of development in better chat/list/calendar clients. Knowing you can get a hold of somebody every time is a benefit that outweighs any other. Same reason Skype hasn't taken over cell/land line phones. Centralized protocols are a necessity. Do they come with limitations for some use cases? Of course. Nothing can be everything to everybody. Which is why the author's point is so well taken: that additional functionality catering to single use-cases belongs at the client level in the form of extensions.
Edit: Also, it seems strange to me that people argue that email is broken because their inboxes have turned into todo lists. I think the reverse is true and people are looking at it through the wrong end. Email is such a simple, useful tool, that people not only use it for its intended purpose (communication) they now also use it for managing todo lists. After all, there are boatloads of todo list software and more and more coming on the market everyday, and yet people still use email while they talk about how shitty a solution it is.
Email is not a reliable messaging system. It gives enough of an appearance of reliability that most people using it think it is reliable. But if you have ever had a very important message disappear into a black hole with no notification, you learn not to treat email as reliable.
Email is not private. But most people do not realize this, and act as if it is. The quantity of proprietary business information and very private personal information transmitted by email is astounding. Governments can, and many do, slurp all email messages. Email "providers" such as ISPs, Google, Yahoo, et al have all your emails, even those you think you may have deleted. PGP/GPG are attempts to add a privacy layer, but have failed because they are too difficult for almost everyone.
Email is useful, for what it was intended for. If you expect it to be something it was not designed to be, then of course you might think "email is broken".
Today there is a need for a reliable and private global messaging system. SMTP is not such a system, but it is still used as one because it's "good enough" and so widespread that nothing better has been able to displace it.
To me email is broken because:
1. a discussion is not a discussion but is a series of messages that happen to have the same subject. The client trying to simulate a discussion is not enough.
2. a message carries all the previous discussion: top posting (or any other way)? This should not be a problem: the other messages are (should be) in the discussion (quoting parts of the message is fine as is).
3. group messaging sucks so bad that I feel dirty when I add more than one recipient to an email. Don't get me started on adding someone to a discussion that has already started or trying to refer someone to a certain email or discussion. Again, I feel like fixing the first point could make this better.
Google tried too hard with Wave (no email interoperation whatsoever, useless protocols to have smarter messages/gadgets, mixing wiki messaging and collaboration), so it failed IMHO. It should have been just the messaging part, embeddable/linked-to a proper wiki, document, collab app. That and supporting interacting with email users via email (this would have the problem that the new system has initially lots of the same pitfalls of email, but not all of them. And with time and the vanishing of email-users, those pitfalls could vanish too). Even if is a different protocol, it should be marketed as a different client.
Ah, the third point: As I see the protocol as open and distributed, I didn't use "group messaging" by chance. That is there to solve the other first world problem that drives me mad.
Gmail uses a different model, but many MUAs shows threads as trees, just like e.g. HN.
To all hungry devs who can't wait to build something amazing: don't try to reinvent the wheel, build on top of it. Leave the email be, and focus on what's next.
Just because something WORKS doesn't mean it works WELL. Making an Asynchronous email protocol would not be difficult. We can do it. Everyone talking about re-inventing email is talking about making a protocol, not centralizing it, not de-synchronizing it.
Email is an AWFUL AWFUL mess. It was good for its era but its no longer as good. Any good replacement will use things like MIME and other such things and simply be a better replacement to the protocol. It'll be the same thing but better.
Which has happened many times before, considering how many versions of POP and IMAP there are. Or the fact that IMAP even exists. Somebody said that email was bad and it needed this and they made it, now we all use it.
Clearly, there is room for improvement.
Nothing is beyond disruption. Just because a technology is sufficiently functional doesn't mean there's no benefit to rethinking it.
I'd like tools that make it not matter so much how I got a message from somebody. It could be an SMTP message or an SMS (or MMS) message or an XMPP message or a message through somebody's privately owned social network. Just put a little logo up in the corner so I have some sense of just what kind of message it was. Other than that, I want all those messages brought together in one place that I control and can get to from any device.
The other note is that the communication is changing. E-mails are less and less like a full mail message, and more SMS-like, almost real-time, and packed with multimedia content. I think GMail is handling that as well as it can. It's surprising how slow it takes us to make new standards when they're obviously needed.
Unfortunately yes.
Just a decade ago we made fun of people sending mails with HTML content because they didn't know better. The same goes for correct email quoting. Nowdays this seems to be commonly accepted - even by people who call themselves "hackers". The only difference is that the omnipresent @hotmail.com has been replaced by @gmail.com.
Email is not broken it does what it was orignally intended to do, namely enable communication between a number of parties. To say its broken because it doesn't do x, y or z is as false a statement as saying my screwdriver is broken because its not good at hammering in nails.
If email doesn't do what you want it to do, then find something else that does. If that does not exist, then build it. Better yet, pay me and I'll build it. :-)
If email really is only a protocol; it would be better to have numerous single purpose apps that use it as a transport. This would be hugely useful in business where email is much less filtered than websites. If people lack the app in question, you could provide a text/html based alternative.
In the work environment, little is more frustrating than not being addressed/cc-ed on some important/critical conversation. Someone leaves your address off, and "Bam!", you're out of the conversation.
I call this the "submarining conversation". It dives below the water, and you remain unaware of it unless or until it surfaces. (Whereupon it often causes considerable disruption. E.g. An entire section of specifications that you were never made aware of.)
Or you are added to an assignment and have to spend time and effort chasing down the various email conversations that have comprised its efforts to this point. AND... once you have them, gluing them together in your head and/or on screen or in text, in order to come up with a coherent and not overly redundant picture.
Google's Wave I saw as a genuine effort to address this. Actually, it is really an iteration on the centrally stored, group conversation. For example, web bulletin boards that were "all the rage" about a decade ago.
Wave added decentralize-able membership controls and sophisticated authoring and version control. Things very useful in a work or similar environment.
It didn't need to be email. But it could better fulfill a role too often filled poorly by email.
HOWEVER, Google slapped a ridiculously bogged down and unintuitive user interface on top of it, then said "figure it out". And so, it died, at least as a Google product and with respect to gaining Google's potential momentum.
SO, I'd say there are some applications of email, that could better be done other ways than through email. But this is not email's fault. It is the result of the limitations of users, both conceptually and in terms of the limited scope of tools that -- particularly in many work environments -- they are supplied and permitted.
P.S. Such organization of conversations pertains not only to contemporary work, but also to compliance and audit-ability. When trying to determine later what happened, with email conversations one it left to obtain, search, and/or reconstruct any number of email archives, hoping that none of the archives nor individual messages have been irretrievably lost or deleted.
Internal message boards are a possible solution to this.
I find this happens quiet often in technology. It is important at times to specify, but I do not think it is always required.
For instance, when you say 'Email is broken and needs to be fixed'. Unless you have the solution I think it is more appropriate to be ambiguous.
When I say "email me," I don't mean "make something show up in gmail," I mean, send me a message over the email protocol. I don't use email as a to-do list. I use it for correspondence, often with people who use other clients.
My conception of email is client-agnostic, and I think almost everyone I deal with (admittedly outside of the tech/valley/startup inside) thinks of it the same way. I hear things like "I'll shoot you an email," or "I need to check my email," or "what program do you use for email?", none of which imply that the speaker intends to be talking about an app.
Texting isn't an app, the telephone isn't an app, email isn't an app, at least for many people.
Yes, but which client? I use mutt, my office manager at work uses Outlook, our accountant uses Gmail, and our advertising manager uses Yahoo.
The fact that we can all email each other seamlessly is inherently because of the common protocol, even though we don't think of it consciously when talking about email.
And Email is just the messenger.
Extending the functionality of Email or What could you accomplish if emails were machine readable?
Email is currently not easily parsable by machines and therefore creates a unique challenge (and business opportunity) to companies that are in need of automating tasks based upon incoming emails.
What is needed is functionality that allows for emails to be easily read and parsed by machines, allowing for things such as bug reports to be routed directly into a company’s CMS or database or to-do’s to be created automatically or any other advanced use that a company may require based upon their own unique business requirements.
What if we could inject a template into an email message based upon the domain name of the recipients email address and or type of email that the user is sending?
Changing the way in which billions of people use email is a large and difficult challenge, the requirement for augmenting the existing system needs to be extremely easy to use from a users stand point as well as from an administrator’s standpoint.
The system, outlined below would not require any change to the way that users currently use email, which from a “take rate” perspective for billions of users is nearly frictionless and has zero adoption impediments.
Templates: Templates would in essence be xml envelopes embedded in the email html body.
Templates are nothing more than xhtml/xml files with embedded html controls such as text boxes, radio buttons or any other valid html controls including basic html elements that an email client can display.
A template would be downloaded and possibly cached on the user’s device from either a global generic template repository for companies that do not wish to create their own or pulled from a company’s public template server.
The template could be displayed in the users new mail message window as a dropdown box of available templates[1]. When the user selects the given template say for instance a bug report template from the drop down list, the xhtml/xml would then be injected into the body of the email message for the user to fill out. In addition, if the email address has a default template, the email template would automatically be injected into the html email body of the mail message.
Template Security: To help alleviate the potential security risk of a template being pulled down from an unknown or untrustworthy source, perhaps because of the user misspelling a recipients email address domain, new templates that are downloaded to the users device would require the user to accept a domains Email Template Certificate (ETC) which would display the companies identity (company name, email address, phone, address, ticker symbol, hash of the existing template and hash of the new one, etc.) based upon reverse dns lookup queries to the domain in question.
For instance, when a user types in bugreports@microsoft.com or other such email addresses, either on the lost focus event of the “To” textbox (for e.g. the user presses the tab button on their keyboard) or on a email clients parse/verify email event a background thread could be started to pull down the most recent templates. Should the user be “offline” a cached version of the template would be used.
Overwriting templates would also prompt the user to accept the new template, displaying items in text such as changes, version number, support and or contact information etc. I imagine it being a prompt (i.e. message box or modal form) with 2 or more tabs, with the front one being a basic overwrite request with written changes from the OEM, date released etc. and the 2nd tab showing a “diff” and other technical details for power users.
Template Parsing: It is inevitable that an email containing a template would be replied to or forwarded to another address or set of addresses. The parsing system should only parse the first template (from a top down POV), placing all other content into a “previous entries” variable. Should an email contain content before the first template envelope the parser shall parse this content and include it in an “additional details” variable, making that, as well as any “previous entries” variable available to the containing systems Business Intelligence modules/handlers.
Template Definitions: A global definition for template types and definitions should be created and maintained on behalf of the system itself, owned, operated and overseen by a board elected by OEM partners and public interest groups, such as the W3C or IEEE does today.
Forgive my crude photoshop skills... http://img59.imageshack.us/img59/5738/emailheaderp.png