Email is not broken, we are.(joshualyman.com)
joshualyman.com
Email is not broken, we are.
http://www.joshualyman.com/2012/04/email-is-not-broken-we-are/
34 comments
Sorry, you missed the point. Occasionally the user is broken, because as human beings we sometimes do things that are less than optimal. I'm not making an argument really for whether or not this is a technology issue or a client/server problem, but more to say that we should try and have slightly more productive behaviors before we expect a technology solution to solve our woes (often self-inflicted).
No, I didn't :)
If this was an "occasional" problem, there wouldn't have been a dozen blog posts on HN about it in the last week (least of all this one). If humans are doing anything sub-optimally that's something technology can help improve. The more common the problem, the more likely there is a common solution.
If everyone wants to use email as a todo list, you have two options: 1. tell everyone not to 2. build it
Option 1 will not work.
If this was an "occasional" problem, there wouldn't have been a dozen blog posts on HN about it in the last week (least of all this one). If humans are doing anything sub-optimally that's something technology can help improve. The more common the problem, the more likely there is a common solution.
If everyone wants to use email as a todo list, you have two options: 1. tell everyone not to 2. build it
Option 1 will not work.
Email is not "broken".
Users are not "broken".
Email is simply a method for people to communicate. People are messy. Put two of them together (communication) and the messiness increases exponentially.
Have you ever seen two people arguing, and then it turns out (much later) they were arguing about two completely different things, and they are actually agreeing with each other? This isn't a technology problem, speech isn't "broken".
Have you ever sent a text message, and the other person didn't respond for a few hours and you started to think that they were upset, or something you said was wrong etc. Then it turns out their phone was turned off or they were in a movie theatre. Everything was fine! Does this mean people are "broken"?
The argument going on in this thread is far too black and white to apply to reality. People live in the grey area. Part of being human is managing the messiness of interacting with other people.
Users are not "broken".
Email is simply a method for people to communicate. People are messy. Put two of them together (communication) and the messiness increases exponentially.
Have you ever seen two people arguing, and then it turns out (much later) they were arguing about two completely different things, and they are actually agreeing with each other? This isn't a technology problem, speech isn't "broken".
Have you ever sent a text message, and the other person didn't respond for a few hours and you started to think that they were upset, or something you said was wrong etc. Then it turns out their phone was turned off or they were in a movie theatre. Everything was fine! Does this mean people are "broken"?
The argument going on in this thread is far too black and white to apply to reality. People live in the grey area. Part of being human is managing the messiness of interacting with other people.
Thanks for the grounding aethr. And toast76 brings up very good points. What I think we've seen recently with all the related articles on HN is a dichotomy of how we are viewing the problem. Most describe it from the perspective of email not fulfilling our technical needs (security, threading, etc.) which is true. There is a lot of work to be done there. I just want to help shed light on a broader problem, where we're shoehorning email into a very difficult problem that is brought on heavily by our own actions.
I don't think many of us on HN want to use email as a ToDo list, but there are other people that we work for or with that tend to use email in this way. For example, my father is a fortune-500-exec-type (and an engineer), and he can't seem to grasp the idea of using a unique subject line (this led me to tell him, "don't email, just call"). There are also people that use the "email this article" function to share articles with you; I immediately delete such emails (I don't do html email), and let them know, but they persist. The issue reminds me of thread-jacking on forums leading to the idea that "forum software is broken."
In other words, there are a myriad of poor choices being made by people that either cause security issues, or inefficiencies using email as a medium that is suboptimal.
In other words, there are a myriad of poor choices being made by people that either cause security issues, or inefficiencies using email as a medium that is suboptimal.
There are stupid users. That is a fact.
Your mantra is useful to try and make an idiot-proof application (and God knows how essential it is to capture a big market share) but sometimes a technology is a bit complex to use and some users who do not accept these constraints are just not fit to use it.
For example, asymmetrical cryptography is not broken, it is hard to use and understand.
Your mantra is useful to try and make an idiot-proof application (and God knows how essential it is to capture a big market share) but sometimes a technology is a bit complex to use and some users who do not accept these constraints are just not fit to use it.
For example, asymmetrical cryptography is not broken, it is hard to use and understand.
I agree. If a technology is causing people to use it sub-optimally, then the technology should be improved.
I disagree. The structure and/or implementation of email is not "causing people to use it sub-optimally".
If you want to manage projects and tasks, there are very good tools available for accomplishing that goal. But don't expect all your clients to start using your management tool because you think it would be "optimal". Email is convenient and easy for them, and they don't have to learn a new system to use it.
If you want to send files to other people, there are already specialized tools for that. Tools that have no size limits, that don't limit file extensions, etc. But don't expect all your clients to start using those tools unless they have a good reason to. Email is convenient and easy for them, and they don't have to learn a new system to send files with it.
There are endless other workflows for email, most of which have a specialized alternative, an "improved" version of the underlying technology. When an individual gets tired of the inadequacies of a certain facet of email, they will find it and start using the alternative. Until that point, they will use email because it is "good enough".
People actually are sub-optimal. I meant to start riding my bike to my new job, the money and health benefits would be optimal. But I'm not optimal, so I'm still taking the train. Until I find a compelling reason to start riding again, I'm going to keep taking the train because it's "good enough". That doesn't mean that the train system needs to be fixed.
Frankly, I think the whole "let's fix email" debate is a complete non-starter, and the bevy of related blog posts popping up for the past two weeks is a whole lot of noise from people who haven't actually thought the complexities of "the problem" through, at all.
If you want to manage projects and tasks, there are very good tools available for accomplishing that goal. But don't expect all your clients to start using your management tool because you think it would be "optimal". Email is convenient and easy for them, and they don't have to learn a new system to use it.
If you want to send files to other people, there are already specialized tools for that. Tools that have no size limits, that don't limit file extensions, etc. But don't expect all your clients to start using those tools unless they have a good reason to. Email is convenient and easy for them, and they don't have to learn a new system to send files with it.
There are endless other workflows for email, most of which have a specialized alternative, an "improved" version of the underlying technology. When an individual gets tired of the inadequacies of a certain facet of email, they will find it and start using the alternative. Until that point, they will use email because it is "good enough".
People actually are sub-optimal. I meant to start riding my bike to my new job, the money and health benefits would be optimal. But I'm not optimal, so I'm still taking the train. Until I find a compelling reason to start riding again, I'm going to keep taking the train because it's "good enough". That doesn't mean that the train system needs to be fixed.
Frankly, I think the whole "let's fix email" debate is a complete non-starter, and the bevy of related blog posts popping up for the past two weeks is a whole lot of noise from people who haven't actually thought the complexities of "the problem" through, at all.
What does the average user want it to do, that it doesn't?
The big discussion lately has essentially come from people who DO know what SMTP is. And apart from "Gmail is slow", from what I've seen there's been a lot of complaining about mostly specialized use cases.
The big discussion lately has essentially come from people who DO know what SMTP is. And apart from "Gmail is slow", from what I've seen there's been a lot of complaining about mostly specialized use cases.
We should be adapting computers to work for humans, not adapting humans to work for computers.
I agree that there are tons of improvements to be made to effective e-mail use in organizations. But many of the behaviors we exhibit are completely natural to us and difficult to change. For example, we check our e-mail on what psychologists refer to as a variable interval reinforcement schedule; we know that at approximately some interval we get an e-mail that is helpful or enjoyable to us, and we waste our time checking for that e-mail.
It's hard to change the e-mail we receive on a global scale in one instant. It's quite a lot easier to develop tools that change how the e-mail we receive is displayed to us. One such concept was the Gmail priority inbox: what if you only got notifications for the e-mail that was important and could buffer up the rest for later?
A complete theory of how e-mail could work might easily involve a hybrid approach. Why aren't people suggesting solutions that could work instead of debating approaches? Does it have to be one way or the other?
I agree that there are tons of improvements to be made to effective e-mail use in organizations. But many of the behaviors we exhibit are completely natural to us and difficult to change. For example, we check our e-mail on what psychologists refer to as a variable interval reinforcement schedule; we know that at approximately some interval we get an e-mail that is helpful or enjoyable to us, and we waste our time checking for that e-mail.
It's hard to change the e-mail we receive on a global scale in one instant. It's quite a lot easier to develop tools that change how the e-mail we receive is displayed to us. One such concept was the Gmail priority inbox: what if you only got notifications for the e-mail that was important and could buffer up the rest for later?
A complete theory of how e-mail could work might easily involve a hybrid approach. Why aren't people suggesting solutions that could work instead of debating approaches? Does it have to be one way or the other?
Great comment enginous. I want to look into variable interval reinforcement now, as I've been approaching this from more of a research-based angle.
The solutions should be hybrid, though I still believe that better behavior, reinforced by technology, is what will be the most effective. If you have your client reinforcing good checking schedules, that's a behavioral/technical win/win.
The solutions should be hybrid, though I still believe that better behavior, reinforced by technology, is what will be the most effective. If you have your client reinforcing good checking schedules, that's a behavioral/technical win/win.
That's a great point: technology can be very effective at shaping human behavior.
You might want to check out the Stanford Persuasive Tech Lab's project on behavior design[0], which has some resources about how to use technology to change human behavior.
[0] http://captology.stanford.edu/projects/behaviordesign.html
You might want to check out the Stanford Persuasive Tech Lab's project on behavior design[0], which has some resources about how to use technology to change human behavior.
[0] http://captology.stanford.edu/projects/behaviordesign.html
I've seen evidence of 'broken email authors' for many years. I'd write a thorough email with explanations and questions and I'd get a reply answering the first question with a single "yes" and no more content.
> When using email, sending tons of short, not fully formed messages is killing us. We need to take the time to construct useful, productive messages, something most of us are not doing.
That's true. Since I began writing well-formed longer emails I receive fewer ones and nearly no IM-style "yes.", "how about that?" anymore. It's also much more satisfying to write and, I hope, to read.
That's true. Since I began writing well-formed longer emails I receive fewer ones and nearly no IM-style "yes.", "how about that?" anymore. It's also much more satisfying to write and, I hope, to read.
Some people are using e-mail like IM and e-mail is built as an asynchronous communication system. In my opinion, that's where the friction happens.
The author of this post brings up a great point about defining expectations on reply times. I think it's healthy to create an auto-reply that states that you only check e-mail x number of times a day.
The author of this post brings up a great point about defining expectations on reply times. I think it's healthy to create an auto-reply that states that you only check e-mail x number of times a day.
I would find getting an auto-reply for every email I send to someone, just telling me they won't be looking at it until later that day ~incredibly~ frustrating. I do not need that email on my phone. I do not need that email in my box. Perhaps a rapportive like sidebar, but not as an email proper, please.
My response is more tuned towards corporate/enterprise/more-than-20-person teams.
so we got salesforce for CRM, getsatisfaction/others for support, jira for project management, tons of enterprise minded apps, yet people resort to email. why? its easier to just type in an email as opposed to logging in / filling a form, and last but not the least treating notifications sent by email in same vein as a human being.
Whats pathetic is "IT" sets up these apps and does pilot program and claims success.
I believe more idiot-proof-apps, as easy as email client app shows up, lesser will be "emails"
so we got salesforce for CRM, getsatisfaction/others for support, jira for project management, tons of enterprise minded apps, yet people resort to email. why? its easier to just type in an email as opposed to logging in / filling a form, and last but not the least treating notifications sent by email in same vein as a human being.
Whats pathetic is "IT" sets up these apps and does pilot program and claims success.
I believe more idiot-proof-apps, as easy as email client app shows up, lesser will be "emails"
The idiot proof app is email.
Email is the digital successor to the memorandum, which is turn the apex of a line of written communication mechanisms dating back thousands of years.
A Sumerian boss got his reports via tablet. Phahroh via papyrus. Roosevelt via telegram. Pershing via a rolled up message tied to a bird.
Instead of futzing around with some fragile app which may or may not be designed for what I'm doing, I can send an email to nearly anyone on earth that I need to deal with.
Email is the digital successor to the memorandum, which is turn the apex of a line of written communication mechanisms dating back thousands of years.
A Sumerian boss got his reports via tablet. Phahroh via papyrus. Roosevelt via telegram. Pershing via a rolled up message tied to a bird.
Instead of futzing around with some fragile app which may or may not be designed for what I'm doing, I can send an email to nearly anyone on earth that I need to deal with.
Couldn't agree more. Email should be something like: "I want to know it, but I don't need to know it right now. Otherwise I should have called you." Let's try to get that back.
It's 2012 we have a 100mb up/down connection and yet I still can't attach a file over 10MB and not have it bounce back. I can't believe that any self respecting hacker does not see room for improvement in that situation. I should not have to work around that situation (yousendit, dropbox etc..) it should just work.
I'm firmly in the "it's broken" camp.
I'm firmly in the "it's broken" camp.
It's 2012. We have servers/services on which we can post files/attachments, either encrypted or access-controlled, and email links to those documents.
But that's just it. Being that it's 2012, the e-mail client should be smart enough to do this. I should be able to attach a large attachment to an e-mail (since that's the logical place to make the association), and then, depending on the attachment size, the e-mail client should automatically move it to Dropbox or some other service and translate the attachment into a link for me.
The difference between the your first approach and the second is that yours requires a behavioral change. The second approach does not. Put another way, it is often easier to change the situation (by making it the path of least resistance) than the person when you want someone to do something else.
It seems like some of this is already in the works, fortunately:
http://www.ghacks.net/2012/02/15/thunderbird-to-get-dropbox-...
Maybe it already exists in certain clients (Exchange and Outlook?) and I just haven't looked hard enough.
The difference between the your first approach and the second is that yours requires a behavioral change. The second approach does not. Put another way, it is often easier to change the situation (by making it the path of least resistance) than the person when you want someone to do something else.
It seems like some of this is already in the works, fortunately:
http://www.ghacks.net/2012/02/15/thunderbird-to-get-dropbox-...
Maybe it already exists in certain clients (Exchange and Outlook?) and I just haven't looked hard enough.
Now ... there's a thought.
Agreed: better to put this in the client than require user behavior change.
Agreed: better to put this in the client than require user behavior change.
Would you be willing to suggest a global minimum bound on the amount of data that you should be allowed to push onto anyone's mail server?
That's the issue, the sender should be doing the heavy lifting (serving the file or at least delegating it) what I propose it more of a seamless imbed/download link on files over a certain size. This could be implemented in email apps using services like iCloud, Dropbox, YouSend it etc.. I know that plugins can be added to certain email apps to accomplish this however that is going down the same path that Netscape did with the browser back in the day and is only now being corrected. Seamless is the goal I should not have to upload/copy/paste It should just be able to take a normal attachment and decide how to handle it based on size etc..
Wow, someone finally gets it. The application isn't broken, the users are.
We expect too much from it, wanting it to be our todo list and other roles that it plainly wasn't designed for.
I email doesn't do what you need or want, then find something else that does. If you cannot, then build it and release to the world.
We expect too much from it, wanting it to be our todo list and other roles that it plainly wasn't designed for.
I email doesn't do what you need or want, then find something else that does. If you cannot, then build it and release to the world.
Your article failed to address the main issue: security. Off by default is broken.
Does anyone else feel that e-mail is not broken, but task/project management systems are?
Fundamentally, doing "productive work" boils down multiple individual tasks which some humans are doing, while at the same time referencing and updating some store of information/documentation/metadata to find what to do, and say when/how it's been done. Computers should be great at assisting with this administration - the bicycle of the mind helps get you where you want to go.
The fact that email is used to move tasks between people, as the place to create new tasks, as the place to discuss tasks, as the default todo-list for a day unless you go out of your way to move information elsewhere, is all not a failing of email or behaviour, it's a failing of project management and shared todo list and documentation systems. They don't do it, so email does.
If you had a place where that kind of stuff was tracked /well/ it would be trivial to use it to do all this stuff and email would fall by the wayside because it would be less good. Email would become for personal, direct contact, and notifications of things that you request be sent to you.
Too much work should not build up in individual inboxes, it should build up in shared project management system - and a company can then choose to allocate more people to it. Asking one person for information because it isn't documented and searchable should not be the norm. Asking one person what needs to happen next because it isn't tracked shouldn't be normal. Emailing prototypes to your colleagues because there is no centralised storage that works nicely shouldn't be the default.
It even seems tantalisingly easy to build - tree structured projects with nested tasks, granular user permissions, a designed UI to answer questions like "which bits need work", "which bits need questions answering", "which bits are underplanned", "what should I be doing". Templates of procedures so you can set regular patterned actions in motion.
It sort of exists. It's sort of in CRM and Sharepoint workflows, it's sort of in individual task lists, it's sort of being made real. But not yet.
Normal cars are no good at moving lots of goods. The way to fix that is not to make family cars with reinforced axles and tractor tyres, and it's not to teach people to drive slower so they can balance things more carefully. It's to invent vans and trucks and trains.
Fundamentally, doing "productive work" boils down multiple individual tasks which some humans are doing, while at the same time referencing and updating some store of information/documentation/metadata to find what to do, and say when/how it's been done. Computers should be great at assisting with this administration - the bicycle of the mind helps get you where you want to go.
The fact that email is used to move tasks between people, as the place to create new tasks, as the place to discuss tasks, as the default todo-list for a day unless you go out of your way to move information elsewhere, is all not a failing of email or behaviour, it's a failing of project management and shared todo list and documentation systems. They don't do it, so email does.
If you had a place where that kind of stuff was tracked /well/ it would be trivial to use it to do all this stuff and email would fall by the wayside because it would be less good. Email would become for personal, direct contact, and notifications of things that you request be sent to you.
Too much work should not build up in individual inboxes, it should build up in shared project management system - and a company can then choose to allocate more people to it. Asking one person for information because it isn't documented and searchable should not be the norm. Asking one person what needs to happen next because it isn't tracked shouldn't be normal. Emailing prototypes to your colleagues because there is no centralised storage that works nicely shouldn't be the default.
It even seems tantalisingly easy to build - tree structured projects with nested tasks, granular user permissions, a designed UI to answer questions like "which bits need work", "which bits need questions answering", "which bits are underplanned", "what should I be doing". Templates of procedures so you can set regular patterned actions in motion.
It sort of exists. It's sort of in CRM and Sharepoint workflows, it's sort of in individual task lists, it's sort of being made real. But not yet.
Normal cars are no good at moving lots of goods. The way to fix that is not to make family cars with reinforced axles and tractor tyres, and it's not to teach people to drive slower so they can balance things more carefully. It's to invent vans and trucks and trains.
I agree with the sentiment of what (I think) you're trying to get at.
However, the problem that some people have raised is that there are many different task management/project management systems out there, and clients interfacing with multiple technology suppliers may not want to learn all of them. Email has one (simple) interface that you can use to delegate tasks to all your suppliers regardless of what management software they use. Furthermore, the client creating the task may not be able to describe it to the same extent that an engineer needs, or know enough to fill out all the meta data required.
To this end, they send their task via email to the engineer (or project manager) and this person enters it into their company's management tool, transmuting it into the appropriate technical specs/jargon at this point.
This may seem like an "extra step", but there are tools for Outlook/gmail to create tasks in popular task management software such as JIRA or Basecamp. Furthermore, someone will likely still have to clean the data up to make it engineer friendly, and assign it to someone. As long as this has to be done, it doesnt seem like copying/pasting an email into a task description is really that much extra work.
However, the problem that some people have raised is that there are many different task management/project management systems out there, and clients interfacing with multiple technology suppliers may not want to learn all of them. Email has one (simple) interface that you can use to delegate tasks to all your suppliers regardless of what management software they use. Furthermore, the client creating the task may not be able to describe it to the same extent that an engineer needs, or know enough to fill out all the meta data required.
To this end, they send their task via email to the engineer (or project manager) and this person enters it into their company's management tool, transmuting it into the appropriate technical specs/jargon at this point.
This may seem like an "extra step", but there are tools for Outlook/gmail to create tasks in popular task management software such as JIRA or Basecamp. Furthermore, someone will likely still have to clean the data up to make it engineer friendly, and assign it to someone. As long as this has to be done, it doesnt seem like copying/pasting an email into a task description is really that much extra work.
This article is a wake up call, thank you.
Marx thought he could change human nature too.
The user is not broken. Wanting email to be MORE than it is does not mean users are wrong. The fact is that email does not do what the average user wants it to do. Telling people to change their habits is...well...stupid.
Before anyone chimes in with "email isn't broken, but the clients may be". Whether this is a client issue or protocol issue is irrelevant. 99.9% of users do not know what SMTP is let alone why it is not broken. The email experience is broken. End of story. No blog post required.