Why Fight Email?

There are problems with email as a collaboration tool.
The worst is email
. A lot of email takes a lot of management. Triaging and
curating email are especially difficult when the email lacks metadata
that enables it to be assessed without opening the email. Even the
email management approaches
take effort, and still result in an
email archive of zero value to a group. For many of us, the email
management problem is exacerbated by the need to limit mailbox size.
The worst contributor to mailbox bloat is file attachments, but even
without that, email is a poor tool for storing and finding documents.

People in organisations want to hold conversations, and collaborate on documents. Work is often done in persistent groups like teams, communities of practice, and customer engagement forums. Most people collaborate in multiple groups concurrently, often spanning multiple organisations.

Common tasks include keeping track of conversations, closely following conversations, and contributing to conversations. We want to participate at our preferred time and place, using our preferred operating system and applications. Finally, we want secure, searchable archives so we can access old conversations, and so that organisations can manage knowledge retention, records and accountability.
Email supports ad hoc collaboration using “reply-to-all”, but this creates disorganised conversations that can only address one topic at a time. Reluctance to increase email load causes reply-to-all conversations to decay quickly, leaving records that are difficult to retrieve. For persistent group email, everyone in the group must maintain their own list of email addresses, and watch for changes to the “cc” list.

In a persistent group, the overhead of managing email is multiplied by the number of members in the group, but still does not result in an authoritative archive of the group’s activity.
Email’s very strength is that it privileges the user over the group. It is inherently distributed. The penalty for this is that email provides no entity, and no repository, for a group. While email is a fantastic tool for one-to-one and one-to-many communication, it sucks for many-to-many communication.

Salvation in Web Collaboration Tools

Promises of salvation from the evils of email abound. All that’s required is migration away from email to a web-based collaboration platform. We are told that wiki collaboration leads to happiness, and that Enterprise 2.0 is about building a collaboration platform that is better than e-mail. Not only is an array of web-based alternatives to email available, but there are phalanxes of implementation experts ready to wrench users away from the most successful software ever invented.

You Can’t Beat Email

Email is the most successful message and file-sharing tool that has ever existed. Consider the criteria for the ideal collaboration client.

  • High Functionality. Supports asynchronous conversations, and file-sharing, archiving, can be searched using metadata or full-text retrieval. Email: check! Sure, use of email for collaboration is problematic, but it does actually do the job, and most people manage around its deficiencies.
  • Low Cost, for licence fees and hardware requirements. Email: check! It’s already running on almost every computer there is, and it’s available for free on the web.
  • High Usability. Email: check! Almost every computer user already knows how to use it, and uses it more than any other tool. The switching cost is zero.
  • High Interoperability. Email: check! All flavours talk to all flavours (if only browsers had the compatibility that email clients do!), and email is blind to organisational boundaries.

What other collaboration client that meets those criteria so well? Email is tantalisingly close to the ideal collaboration client. Why are we throwing it out?

Throwing the Baby Out with the Bathwater

Once the licence fees, hardware requirements and deployment of the new collaboration platform are taken care of, people will have to stop what they’re doing now, and learn to use a new system for collaboration.
Each user faces the cost of abandoning the system they know, and climbing the learning curve to the new system, amidst the pressure of daily priorities. If any user baulks at this cost, you have n-1 uptake of your new system. Unless that one person is superfluous to the team, the other team members must accommodate them by duplicating communications in the new medium, and email, or reverting to just using email.

Even with 100% internal adoption, the system may not work well across organisational boundaries. Even if it does, you now to get users outside the organisation to use your new system. Hopefully, they are not being marshalled into a different collaboration platform at the same time.

In their zeal, the crusaders for change scoff at these barriers, and declare that the benefits offered by the new system makes it worth taking the pain. Not only that, but they decide that, along with the migration, there will be a purge of old bad habits that have crept across the organisation. Everyone will now start thinking about the greater good, and apply metadata to their documents and communications.

In a final blow, because the new collaboration system is web-based, it is inherently a pull medium, not a push one. It therefore uses email to notify participants of new activity. Your users can keep using email to follow conversations if they want to, but they have to leave email for the new system to contribute.

It’s Not All About Implementation

What if the cost of teaching people to use the new system was invested in teaching people to use email better?

The problems with email can be mitigated to a large extent, by adopting improved practices. Writing good subject lines is a great place to start. Using search, rather than folders, to organise email works for many people, and if you do use folders, message rules make a big difference. But improved practices alone will not overcome the limitations of email for collaborating in persistent groups.

What is required is some kind of technology that allows people to keep using email, more or less as they do now, but makes it easier to use email to collaborate in groups.

There is a Technological Solution

A system that supports group collaboration using email should allow users to contribute as well as access messages and files using email. It should also provide some shared repository that can be accessed over the web, regardless of location. The shared repository should archive all communications and be searchable, but it should also support day to day participation in conversations, and document-sharing. Ideally, the tool should provide equivalent functionality via both the its web and email interfaces.

Technology that provides this functionality is easily found: email groups. The best-known examples are Yahoo! Groups and Google Groups, and of course there is our own service at OnlineGroups.Net.

Email Groups Make Email a Collaboration Client

Email groups are a simple but flexible technology that supports semi-structured group communication, accessible via both email and the web.

The group has a name, an email address and an address on the web. Any group member can email the group, and the group sends that email out to all group members. All posts and files are accessible in a central repository on the web, where users can also add posts and files. Groups have persistent membership and discoverable privacy settings and joining criteria. Group members maintain their own email addresses and delivery settings.

Email groups overcome the primary weakness of email, by providing an entity, and an interactive repository for a group.

Email Groups Overcome the Problems with Email

Firstly, even if users do not write better subject lines, the message headers inherently contain more metadata. The group address and, if set, subject line prefix, instantly signal the context of the message, including the participants and purpose. Even if the subject line is broken, the sender, and senders of other messages with the same subject line provide further data about who is doing what in the group. If messages are not filtered, often they can be deleted or marked as read, without needing to be read, as a full transcript of the conversation is available on the web. This makes is easy to triage email, to keep track of conversations, to schedule detailed attention to conversations. Topic digests, and web feeds provide further ways to support these tasks.

The aggregation of group-related posts in a web archive supports the task of closely following conversations, and contributing to conversations. Posts are organised into separate threads or topics, and sorted by date, making it easy to follow one or more concurrent topics of conversation, whilst ignoring the others.

Files are stored in the central repository, associated with the messages that relate to them. Versioning is handled by the deceptively simple process of adding successive versions to the repository. This eliminates mailbox bloat, while providing an audit trail of all document edits.

Simple improvements to practices can increase these benefits considerably. Writing good subject lines means that even more emails can be triaged from the inbox. The text of previous messages is already in the archive, so it can be removed, increasing the signal-to-noise ratio.

With good subject lines, keeping track of who is discussing what is even easier. In the following example (from the OnlineGroups.Net Administrators group), it can be seen that Dan and Annelies are discussing Chat, and that Michael has responded to Kirsty about Adding Members.

Who Is Discussing What

Email Groups for Organisations

At OnlineGroups.Net, we used to use Yahoo! Groups extensively to facilitate collaboration for our clients. These were successful because of their killer feature of working as well via email and the web. Our clients, however, began to demand greater control over the context of their email groups. They wanted their branding, not that of Yahoo!, around their email groups, and they definitely didn’t want ads from arbitrary third parties. They wanted their groups at their own domain. They wanted more control over the administration and privacy of their email and document archives. They wanted their groups grouped in a single context, rather than appearing alongside unrelated groups. And they wanted to be able to associate web content with their groups.

GroupServer and OnlineGroups.Net

To meet these demands, in 2004, we built GroupServer, an open source collaboration server, providing email groups, in a web content and application framework. GroupServer has been in production since then, underpinning sites used by clients like Advanced Business Education Ltd, and E-Democracy.Org. GroupServer version 1.0? is available for free download at GroupServer.Org.

Because GroupServer sites can distribute millions of emails a day, they are not trivial to administer. OnlineGroups.Net therefore provides access to GroupServer sites and groups via its software service at http://onlinegroups.net.

4 Responses to “Why Fight Email?”

  1. John Tropea

    Great post, you see socially managed conversations and files that live at a central archive as the ideal scenario. But there are going to be adoption issues using new tools to achieve this, so why not involve email in the process, as do many of the group sites on the web.

    I do like the idea that you can publish a blog post/forum topic by sending an email to the blog/forum special email address.
    Others will receive this content as a new email, and can use the email “reply” button to leave a blog comment/forum reply.
    A folder can also have a special email address so you can email an attachment into a folder in the central archive.

    There are also tools like 9cays where you can create an on the fly blog post discussion by email.

    This works for announcements, and discussions, but what if you want to collaborate on a document, or converse around a document. I don’t think there is a good email way to get around using a wiki.

    Also I like the idea of people visiting the group site, checking out stuff that wasn’t emailed to them, bumping into stuff.
    I like the ideas of profiles, checking out a persons bio, their blog posts, forum contributions, bookmarks, interest tags, which people they are connected to. Email is really hopeless for discovery, profiles enable a global company to be a perpetual coffee room with people walking around with name tags and their content on their sleeves.

    This discovery makes for new people connections, new conversations, new collaborations…horizontal value.

  2. Dan Randow

    Thanks for your comment, John.

    With OnlineGroups.Net, there are no folders. Files are organised into topics, just like messages are. Topic titles can be defined on the fly, either via the web or by changing the email subject line.

    As you say, this does work well for announcements and discussions. It also works well for collaborative document editing. Group members edit and upload successive versions of the document to the online group. As one group member often takes the lead in document-editing, the need for concurrent document-editing is outweighed, in my view, by the usability problems with wikis. Most people can use tracked changes in Word or Open Office, and they are fine for merging multiple document versions.

    Your idea of profile-based discovery is very similar to ours. You can see my posts on this site, for example by visiting my profile.

    We are also interested in a blog that supports email interaction by the way, and we’re planning to implement an OnlineGroups.Net group that works like a blog, one day.

Leave a Reply

You must be logged in to post a comment.