Email is not broken, we are.
joshualyman.com
joshualyman.com
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.
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.
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.
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.
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.
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.
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.
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?
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.
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
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.
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.
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"
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.
I'm firmly in the "it's broken" camp.
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.
Agreed: better to put this in the client than require user behavior change.
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.
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.
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.