One of the main requirements for the Collaborative Tools Project is collaborative document editing. A group of researchers, at York want to be able to work on a paper or a research bid document with researchers at other organisations. You’d think that by now this would be a solved problem wouldn’t you?  Some of the first GUI computers in the 1970’s created were designed to be used by two people, each with a mouse of their own, so surely by now collaboration should be as natural as a mouse gesture. It’s not.

The two most commonly used approaches for working collaboratively on documents are a. wikis where the document lives in one place online and b. emailing documents around lots of people. Both of these approaches are flawed.

The Problems With Emailing Documents Around

• You receive feedback from seven people about the same typo
• The latest version is sent to Jill who is on holiday and you have edits you want to make
• Someone on the team doesn’t have the “right” version of Word
• Someone just joining the team has no idea of “how we got here”
• It’s difficult to add comments to text (without adding text to the document)
• It’s difficult to know who added what. I’ve found most people aren’t comfortable with merging documents at all.

p.s If you are in the hell that is emailing documents around then CompareMyDocs (for merging) and CC Betty (for keeping track of who has the latest version) may help. I’ve also had a quick look at Alfesco (an open source replacement for MS Sharepoint) but deep down I feel that documents themselves are the root of problems so I keep looking for “document free” solutions to the whole collaborative editing itch.

The Problems With Wikis

• The editing screens are often ugly and difficult to use. Nobody should have to learn wiki markup.
• They often only work online, meaning you can’t edit the latest version on the train.
• The interface, being browser-based is often slow or even worse “faulty” resulting in people losing their carefully crafted work.
• Many wikis don’t handle concurrent saves very well, resulting in you losing other peoples’ carefully crafted work.

There are some interesting attempts at solving the collaboration problem, including Google Docs. Here’s a collaborative document about collaborative documents (shown below).

Google Docs (like most document editors, whether online or not) is poor at document navigation. Most of the document editors out there almost assume that you start at the beginning and then write until you’ve finished, whereas most of us jump around a document filling in the bits that we can. This jumping around (or what Jef Rasking called LEAPING ) is normally only ever done with the scrollbar which is woefully clumsy way of getting to the bit you want to edit.

Despite Google Docs being one of the most interesting tools, other alternatives have features worth exploring. I’ve been using Zoho editing tools recently, which have been integrated into a workgroup application called Huddle. Did you know they have an API meaning that you can embed a Google Docs quality editor in your web application?

Adobe Buzzword (apart from looking nicer) has the ability to add comments (or annotations) to the text. You can see the mess that Matthew and I got into in the Google Document (above) as we added our comments to the document. It took us a while to work out that we could assign colours to our comments and there isn’t a key (I don’t think) that keeps a track of who is which colour. I think annotation is as important as actual editing and is often overlooked in these sorts of tools.

One tool that tries to tackle annotation head on is Revizr. It’s not the clearest of interfaces, it could do with a Web2.0 lick and spit, but I like its thinking.

Etherpad, the “real time collaborative editing tool” is also worth a mention. Although it has a limited set of tools (this in itself may be a good thing) it’s nice because it is so immediate (see below). What I like most about Etherpad  is…

• people are automatically assigned colours (which can be removed later)
• there is a “chat room” (bottom right) so that you can discuss the changes you are making without them becoming part of the content.
• I also like the fact that this chat room is time-ordered, whereas the document may “evolve” over time.

Etherpad has just been bought by Google, which probably means either Google Docs will inherit some of its features.

All of these tools seem to work better in different situations, or on different points on a collaboration lifecycle… which might look a bit like this… When you look at the process of putting a research document together, in really simple terms, there are distinct phases each which might need it’s own user interface.  For example, Etherpad works really well for documents around a page long but when the text is longer, people can be working on a completely different section and you have no idea that they are busy working away.

So far, I have yet to find a collaborative editing solution I’m completely convinced by. Tools that try to solve the problem by over computerifying the workflow end up too difficult for occasional users. Tools that totally mimic word processing applications are kind of starting from the wrong place. For me, I think all the opportunities for innovation are in the early and late stages of the collaboration lifecycle above, in collecting ideas (brainstorms etc),  shaping or outlining and finally annotation (or adding comments and content without changing it). We already have a plethora text editors that work well enough or work the way we want them to. I’m looking for tools or processes that support the whole process rather than just the middle bits.