Slashdot Mirror
Why Email is a Bad Collaboration Tool
An anonymous reader writes "Isaac Garcia follows up his popular "The Good in Email" article with "The Bad in Email or (Why Steve Ballmer is the CTO of Microsoft)":
"In spite of email's universal success (as a collaboration tool), and in spite of its many good traits, email contains deep, inherent flaws that force users and markets to seek alternatives to collaborating via email."
Wait a few minutes
Yeah, I think I'd pretty much wait for you in the parking lot after work. And I wouldn't be there to give you a hug, ifyaknowwhatimean.
Oh, by the way, my boss has it somehow set to default that it's urgent and he needs a response once I've read it. Same with his secretary. Urge to kill rising
My work here is dung.
An intelligent user of email considers whether sending an email is appropriate for the communication at hand. That's the way it is with so many tools--they're often misused, but that doesn't mean they don't still have their proper place.
The summary states the title of the article as: "The Bad in Email or (Why Steve Ballmer is the CTO of Microsoft)"
Two problems with that:
Problem #2 is especially difficult to understand, as the article itself correctly identifies Ray Ozzie as Microsoft's CTO.
____
~ |rip/\/\aster /\/\onkey
What I mean by silo'ed is that email traps information into personalized, unsharable, unsearchable vacuums where no one else can access it - the Email Inbox. Think of your Email Inbox as a heavily fortified walled garden. Not mentioning the difficulties many have accessing their Email Inbox outside the corporate firewall, the Email Inbox contains a hodgepodge of business, personal and private information that most people do not want to share with others.
Unfortunately, the Walled Gardens of our Email Inboxes are deceivingly warm and cozy. This feigned-comfort of safety whispers into our ears like a wily devil to, "Just email the document to me" or "Just email that document to yourself" with the false-belief that it will remain safe, secure and locked away. But that is just it......its locked away so that NO ONE ELSE CAN ACCESS IT. This is counter-culture to team collaboration.
And how many times have you sent out a document for comment and gotten back 30 different versions with markups, which you then have to reintegrate into one document and somehow handle inconsistencies and overlap? Then of course you need the document, but don't have a copy where you're at, so you retrieve one from an email and use that, but it's an old version, so you have to recreate revisions. And then someone always emails you their revisions late, after you think you're all done (usually it's your boss, so it's not like you can just leave them out).
If nothing else, you need a document collaboration tool, to avoid this nightmare of multiple files, and email is not it.
GetOuttaMySpace - The Anti-Social Network
I believe the problem with Email is usually only 10% of what you are trying to communicate is actually understood.
:-)
Sort of like posting on slashdot.....
RTFG - Read The F#$%ing Google!
From the article:
The single worst trait of email is that it's silo'ed.
Then he says:
For many folks, the Email Inbox contains their most intimate secrets all mashed together into a single location: business correspondences, contracts, proposals, reminders, tasks, love letters, indiscreet online purchases, dirty jokes, pictures of your spouse (and kids), time-wasting games, inappropriate messages from co-workers and friends and lets not forget spam.
To me it seems like the perfect argument for why email should be silo'ed, and that it's one of the reasons why it is still so popular. I completely agree with his comment that there is a wealth of information hidden within emails that others could/would find useful. However, there obviously is even more that most would find useless or that the inbox owner wouldn't want visible. To me email represents the best, if flawed compromise. If the inbox owner wants to, they can redistribute their emails to a wider audience. This can be done by forwarding, or in Outlook, simply dragging the email to a public folder. I think the alternative approach, assume that everything is public and force the user (either sender or receiver) to selectively "hide" or "target" emails falls too far on the "other side" for most companies.
In development over the last 5 years I think the most useful tools are IM (or IRC) and Wiki. Email can be used to setup a time to meet/work on things, from there constant talk back/forth via IM is perfect. Hashing out overall ideas via the Wiki is perfect for before and after, and allows for ones ideas to get fully out there, then edited by others during critque.
This has been true for me working on OSS at night with a partner in Qubec as well as working in the same office with a developer two aisles away.
fak3r.com
A fairly insightful article, but it misses a couple of points:
It's difficult (if not impossible) for the average user to discern who an e-mail is actually from. Most people have no idea about message headers or IP addresses. It is trivial to send e-mail spoofing the address, and have 95% of people unquestioningly believe it's from the address you specify. This is one of the biggest and easiest to exploit weaknesses in e-mail.
E-mail is incredibly easy to ignore. Really, really, really easy. Claiming you didn't receive an e-mail is a get-out to any number of problems in collaborative projects, mostly because it's so common - it's fairly easy for an e-mailto not get to its recipient, be it an over zealous spam-filtering policy, a misconfigured mail server somewhere along the line or a lack of space on a company intranet (combined with badly configured mail servers which are relatively common).
"If you are using POP or IMAP, you need to know that they both require you to send unencrypted authentication (username/password)."
Ah, not necessarily. Especially in the IMAP world, see IMAP over SSL.
[insert story about linux box and IMAP/SSL/MUTT]
Here's the real problem: You tried to scare your audience with concepts that your target audience doesn't understand. You can't scare ignorant people, see low limit Texas Hold'em.
Anything is possible given time and money.
Crap. Crap. Crap.
Good, now that that's out of my system, I'll explain.
Email WITHIN my domain is guaranteed. Honest. If someone (say joe@jupiter.lan) sends mail (to, say, jane@earth.lan), its going through.
If joe@jupiter.lan sends mail to peter@scrape_me.com (whatever), it is rewritten to joe@scrape_this.com, and forwarded to forward_this_shite.net.
After which IT ISN'T MY RESPONSIBILITY. If it can't be forwarded on, it WILL be returned to joe@jupiter.lan. Once accepted, though, I don't care. Not my network. And this makes the world go around.
If there are problems within your LAN or your system, its your responsibility. The original Unix just dropped the mail into the file system. Which is as reliable as the file system. No delivery issues. Linking networks together; as reliable as the linking/forwarding services used.
I can't and won't be responsible for other peoples networking and administration skills.
Ratboy
Just another "Cubible(sic) Joe" 2 17 3061
There is a way to use e-mail as such a tool, which was the preferred method used by the Spanish Al-Queda cell:
1. Open e-mail account (on your own web mail server, preferably) and publish username/password to members of cell/department/workgroup.
2. Write e-mail detailing plan and save as "draft."
3. After connecting by SSL, other co-workers/conspirators view and edit draft or attach comments for all to browse and update.
4. If server is owned by group, files are as secure as the passwords and OS. If a public/commercial server is used, drafts and connection IPs may be discovered and will persist on backups and logs.
Part of this article drives me nuts, and I see the same crap in /. comments all the time:
2. The data is often 'NSFW' (Not Safe For Work).
Why did he use the acronym if he defines it directly after use. The only reason he should do this is if he used 'NSFW' elsewhere in the article, which he does not. The writer should decide whether he feels this acronym is recognizable enough to use without a definition. If it is then use it, otherwise don't!
Fixed:
2. The data is often not safe for work.
nothing
E-mail will have been dead for close to a decade in 3 years. Yes, we all still use it. Yes, it is a primary form of communications for anything over 30 miles. And yes, the horse is dead but we'll still beat it.
I stopped using e-mail as my primary form of communications almost 7 years ago (about the time I started using SMS en masse, combined with instant messaging when available). For me, e-mail is no different than TV, radio and telephone -- all technologies that should have been replaced eons ago but for whatever reason have been held back from evolving.
I agree that e-mail is a terrible collaboration tool, but considering when it was "invented" and how few real iterations of change we've seen with in, I don't expect it to ever blossom into a truly useful tool for productivity. I would have to guess that while e-mail is more efficient than a fax or a letter, it is not a telephone replacement, nor is it a replacement for even a simple post-it note. The only collaboration-friendly element of e-mail is the idea that it leaves a log or an audit trail of exchanges, but it is missing all the other important elements for group-think or idea creation.
I believe the future of connecting everyone within a group to one another plus incorporating outside groups into the "conversation" will likely come out of a different technology than e-mail. I see great possibilities in RSS and XML as a platform for long term collaboration, and the Wiki idea is a step in the right direction. Combine both with a tagging feature and incorporate more than just text, and you have a mess of protocols that together can really make a difference for building and sharing ideas. Maybe a little slashdot-style user-modifiable open-view moderation, too. Before any protocol or format can be created that really is the end-all solution, we need the underlying platform to be finalized. We need the Net available all the time, everywhere, at low cost (commodity-priced) and at high speed. I believe that the EDGE/3G networks are getting us closer (I am typing over an EDGE-connected T-Mobile link now), but we're not there yet. When information can be accessed immediately, when notifications can become part of the data stream, and when the ability stream your thought into a final product with anyone else, I think we'll see that product that many of us are waiting for without knowing it.
I've given a lot of thought to collaboration tools of the future, and I know exactly what I want. I just know that even if I implemented it today, most of my workers, friends, co-writers and readers would not be able to mesh with the Wiki-XML-SMS-Slashdot-tagging tree with the speed that I would think is necessary to make that collaboration better than a simple whiteboard and a boardroom.
Another few months, maybe. A few years, for sure.
Use registered post. Seriously. IP itself is unreliable. The Internet is reliable in the sense that the global network does not go down even if some sites (or backbones) do.
Modern email is pretty much reliable. What is not reliable is the "business" need driven content filters which cause mail to disappear.
SMTP is best effort, and that effort is very, very good. End users can make the best efforts of clued administrators fail.
Reject my email if you think it is spam. Don't filter it out, because then I have no feedback (and no, read receipts aren't acceptable).
I can throw myself at the ground, and miss.
1. "If you are using SMTP (the universal pipe, remember?), you need to know that it doesn't encrypt data/messages. If you are using POP or IMAP, you need to know that they both require you to send unencrypted authentication (username/password)."
None of these is true. Encrypted SMTP, POP and IMAP all exist and we've been using encrypted POP/IMAP where I work for over two years now.
2. In the discussion of encrypted e-mail, he jumps straight into certificates with no acknowledgement or apparently even clue that PGP/etc. exist and are a lot simpler to set up and use (even in Outlook, or even manually if you have to).
3. "Eudora Security Flashback: I still don't know what the hell Kerberos is and what it has to do with a dog much less my email?"
Considering that this guy is, judging from the content of his post, very Microsoft-centered, for him to not know what Kerberos is suggests he is not even close to any kind of expertise in the field.
4. "Most companies spend a fortune locking down their IT infrastructure. This results in either Total Lockdown, also known as Paralysis whereby no one can do anything without a password, passkey, keycard, signature and sign-in sheet; or in No Lockdown, also known as Free-Love-Utopia whereby everyone is equal because everyone is an Administrator."
Um... no? He says "This results" as though these alternatives are the only two possible. This is probably just sloppy writing, but it still sticks out at me.
5. "If everyone used Outlook (70% of Central Desktop users use Outlook), then the ability to assign priority to each message would actually work. But we don't live in a Microsoft world (in spite of what many of you might think) and instead, we usually measure and weigh the importance of an email message by the number of people included in the carbon copy. This is highly subjective and fails to address the need to order and sort messages and task by importance."
I know from personal experience that Eudora among others had the capability to set and recognize a Priority or read-receipt header as long as 10 years ago. Priority fell out of favor because of abuse by spammers, but it does exist. And that was valid for any message sent to or from anyone on the Internet. Can we trust Outlook's read-receipt and priority flags to be as portable?
6. "Its still challenging for multiple people to share business email accounts (i.e. support, bugs and sales messages). IMAP sort of works, but presents its fair-share of limitations."
Such as? How could IMAP be better? Given the inherent needs and limits of sharing what is essentially a file folder, I think IMAP is designed about as well as it can be. There could be improvements, but nothing I can think of that would make me go "wow! It's a whole different IMAP!"
7. "Email is Prone to Viruses - There is no need to elaborate here."
Yes there is, because (say it with me!) E-MAIL IS NOT PRONE TO VIRUSES. E-MAIL CLIENTS ARE.
There are some good points in this article, but you have to filter them out from the sophistry.
-- Old Man Kensey
CTO = chair throwing officer?
I'm going to be starting on a spare-time open source project pretty soon and was wondering what people recommend for collaboration. The biggest project I worked on was the jboss portal server(previous version) and communication to developers(non-jboss employed at least) seemed to be mostly by email and forums. It was a little hard to know for sure if someone else was working on the same thing as me until a cvs commit. All the jboss guys I delt with were really helpful, but because of some of the reasons outlined in the article I kind of always wanted a better way...
Thankfully the new project I'll be working will have 2 main developers in the same city so we'll actually have some sit down sessions but so far almost everything is in email. What are good collaboration practices(the article mostly just said email sucks)? For software I'm currently investigating gforge with the wiki plugin. Does the slashdot community like wikis for collaboration between developers on software development projects or something else? Does all this really get solved when you have a dedicated project manager? Should your collaboration tool also be your project management tool? Any good project management tools(esp. ones that combine collaboration software). Thanks!
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
In fact, SMTP offers a number of secure alternatives, included TLS within an otherwise unencrypted pipe, or SMTP/SSL on port 463. POP and IMAP both support TLS for 110/143, as well as POP3S/IMAP4S over 995/993, and have not required plain-text login since the introduction of capabilities negotiation more than a decade ago -- both of them support a version of the AUTH verb. (To give you a sense of time, the relevant RFC's were published before Netscape developed SSL v1, back when sending creds over the wire in clear text was completely standard.)
The guy's trying to sell something, but it would help if he could sell things without lying about them.
Thunderbird would spread like wildfire if it could do secure, guaranteed (to arrive, or notification if not) email.
It can. For many people, it does. Also, you're confusing a client issue (secure content) and an only partially client issue (secure delivery) with pure server issues (guaranteed delivery) which the client should not and in fact cannot address. And that issue is solved anyway, in SMTP, for what, 30-some years now?
-- Old Man Kensey
Most senders I've received E-mails from assume I received and read the mail within 5 minutes of their sending it. Scheduling a meeting for 20 min after sending the mail notification is rediculous, or sending it right at the end of the workday (or later) and assuming I'm so eager to read it I access my work E-mail from home. If its that important PHONE ME! Just because you sit all day at your desk with your E-mail open doesn't mean I do, two way communication is the only way to confirm a message is received.
Winston Churchill once said "Democracy is the worst form of government except all the others that have been tried." You could say the same thing about email as a collaboration tool -- it sucks, but for the average user it sucks less than every other option.
None of these objections are so large that they can't be overcome; many people use the tools above successfully. But for the average user, who accepts defaults and isn't interested in learning a new skill just to organize a meeting, they all have flaws that outweigh the flaws of e-mail.
I hate collaboration-by-email as much as the next guy, but until we can come up with something that is an order of magnitude better for the average user right out of the box, we shouldn't be surprised if they keep shooting e-mails around. (sigh)
Read my blog.
hmm. what exactly are excuses ?
as i saw, ratboy stated that this can not be guaranteed unless all participants comply with common rules or all links are controlled by a single entity.
if all links in an email-processing chain (your mail client -> your computer -> your server -> some other mailserver -> other computer -> other mail client) are working as they should, the message simply will be delivered.
now, wether it will be read... no, read notifications is not a good idea.
generally mail system is supposed to notificate you whenever there is a problem delivering the message - wether it would be unaccessible recipient server, incorrect recipient address, unaccepted content or whatever.
it will usually do this by sending you an email message stating that the message was not delivered and telling you why. in some cases you might get notified immediately, if your server can find a problem while your mail client is talking to it.
once the message has left your mailserver, it's completely the responsibility of other server[s] to inform you as a sender about any problems that result in inability to deliver the message to the final recipient.
phone conversation isn't exactly a good analogy as it's a two-way interactive communication. unless you propose one mail client talking to another, there always will be intermediate servers that will pass the mail, check it for viruses etc.
if you ever get unreliable mail delivery (meaning mail is getting simply lost), that SHOULD NOT HAPPEN. really. contact your administrator, together with him try to find the cause for it. once it is found (you might have to contact destination/sending party), push for it to be resolved.
now, the only case i can think of missing mail (that is not because of some massive network or infrastructure outages that you should be noticing anyway) is spam filters. yes, spam filters that discard messages can cause this, but anyway are controlled by one of the sending/receiving party, thus finding which has snapped the mail and preventing that from happening should be done as soon as possible. and the message itself still must be possible to retrieve from the spamfilter if, for example, it's your organisation's infrastructure that has classified the message incorrectly.
other approach is flagging all the mail and letting it to fall in a separate mailfolder at user's client. that is easy to do with current tools and probably is the best thing to do at your organisation if losing email can be critical and users are sophisticated enough to find the occasional filtered away message (and they have the possibility to set individual thresholds so that one would have more manual spam-hunting to do, other would cope with a mail getting classified incorrectly now and then).
Rich
Maybe the programmers figured the people wanted to read the mail once it got delivered...
May contain traces of nut.
Made from the freshest electrons.
I do wonder why you sound so bitter about it, though.
I find the attitude of the OSS community depressing about this subject. They are too close to the technology and can't see the flaws in it.
Email is and should be recoginized and used for what it is, "Electronic Mail". Not "URGENT NEEDS A REPLY INSTANTLY"... NO! I do not check my email every five minutes, once or twice per day.
If you need an instant reply, how about use something like "Instant Messaging", VOIP, a phone call, or come over in person?
I really hate people who expect email to be almost the same thing as instant messaging. Email is a lower priority messaging system, it should not be used for something that you need an instant reply to.
The system should be designed so that emails can never be silently lost.
/dev/null. Once /dev/null reads the contents of the e-mail, it is read as far as the software is concerned. You'll think I read the e-mail while I'm blissfully unaware that you ever sent it. Redesign e-mail all you want, but it's impossible to guarantee that any form of computer information exchange happens successfully when you aren't in control of the receiving end.
Care to share exactly how you would ensure that is true? It can't be solved at the protocol level, the receiving end could make a mistake, or simply lie.
What if the admin accidently pointed my mailbox to
Yes it's annoying having to guess if your e-mail made it or not, but this problem can only truly be solved socially.
IMHO a simple improvement to email would be no more than twice a day delivery.
Let me guess. You have stock in fax machine manufacturer?
The fact of the matter is that emails that many people suffer a lot of problems with emails, from my old ma to the CEOs of large companies. The current email system is flawed. Telling me that it's perfect or that it already does everything that everyone want is just frankly rubbish. The reason I find this subject so annoying is that one day there will be a better messaging system than email, but it looks like it's not going to come from the OSS community.
.... uh .... I never got the email. Yeah." People lie. Deal with it-- it's not the email protocol's fault, nor is it the protocol's job to police it.
OK, here's where I think you are confused; perhaps no one has taken the time to explain things to you without getting too technical.
There are three* types of "undelivered" email, that would all get your mythical red dot, if I understand you correctly:
1. Email that was sent to an invalid address. A user sends an email to joe.m.bloe@company.com, except that he meant to send it to joe.t.bloe@company.com. In this case, the company.com mail server will "bounce" the email: the sender will get an email message saying, essentially, "I cannot deliver this message because there is no user named joe.m.bloe." If this bounce response is not sent, it is the fault of the administrator, not of the email protocol.
2. Email that has not yet been read. Some people might consider this "undelivered", although the server considers it delivered because it made it to the right mailbox. What happens after that is the responsibility of the recipient. If you simply HAVE to know when your message is read, then attach a read receipt, which is built right into the protocol. (Please note: most people don't like being spied on, and will not send a receipt when asked by the email client.)
3. Email that simply goes missing. This breaks down further into two categories:
a. Filtered email. The administrator of an email server can choose to filter mail, either to take out spam, curb inappropriate content, do virus checking, or whatever. False positives in this situation (non-spam email that was filtered and deleted) are the fault of the administrator/spam-blocker, not of the email protocol. The sender should be notified if a message he sent was filtered.
b. "Lost" email. "Oh, the reason why that report isn't finished yet is because
So the reason why most people on Slashdot aren't taking to your idea is that the current system can handle all the various contingencies that might come up. If your emails really are just disappearing without a trace (and you're sure no one is lying about it) then you need to have a serious talk with your administrator about what can be done, because there is something wrong with your company's mail system.
Many email servers are poorly administrated, it's true. But no amount of coding by the OSS community will fix that. It's not a technical problem at that point; it's a social one. The current protocol contains everything necessary to "guarantee" mail delivery, if such a thing is possible when humans are part of the system.
On the other hand, if you're just looking for an email client that will place a red dot next to an email conversation that received an Undeliverable Bounce from the server, then you might want to go suggest that feature to the Thunderbird people.
----------
*There is a fourth category--where an email was not forwarded on by one of the middleman servers between point A and point B--but given the generally robust nature of the internet, unless you are using some shady email server that might flake out at any moment (again, the fault of the administrator) or sending your email through shady proxies, the chances of this happening are so very slim as to be completely negligible.
For security, the MD5 hash of this message and sig is 09f911029d74e35bd84156c5635688c0.
I think this article misses the point of email entirely. Email is good for sending a message from one place to another. I don't think the originators of email saw it as a document management tool, a revision manager or any of the other hundred things people try to jam into it. It's amazing what people've been able to do with such a simple set of protocols, but it's kind of like complaining that your car doesn't make a good hot dog stand. Sure, you can sell hotdogs from it, and you can put buns in the glove compartment or paint it cool colors or advertise on it, but at the end of the day, it's a thing that gets you from point a to b.
Blaming Microsoft because they've added things to make it possible to collaborate badly is just silly. They've just added a pink bun warmer to a honda civic. Extraneous and barely functional? Sure. Their fault this doesn't make it the perfect hot dog stand? Not really.