** Note: I'll be roaming around with limited internet access until sometime Sunday. I will moderate comments when I can. **
Last spring, I wrote about my efforts to get a group of people to work on a collaborative writing project. I tried a wiki for the first attempt, with little success.
Later I tried Google docs, which had some advantages over the wiki, but it was not significantly more effective or efficient than the classic method of sending lots of documents and parts of documents as e-mail attachments. Most text was sent to me, the main organizer of the project, and I compiled everything.
The group seemed to glance occasionally at the collaborative document online, and that was convenient because it reduced the number of drafts that I had to e-mail to everyone. We never reached the point, however, at which most participants were using the online document for their major editing. One or two did some editing of the online document, but most preferred the classic method of sending me comments or attachments by e-mail.
My being the group-write hub was convenient in some ways because I was able to work on the overall document bit by bit and integrate the various parts. In the end, the final document reflected significant contributions from a large number of people, each with a different style/format of writing, but the text ended up being coherent.
I think it is interesting that the online document/collaborative writing method wasn't particularly useful (or, at least, was not well used) for this project, and I still don't really know why my colleagues weren't comfortable editing the online document. I'm not sure what it would take to make an effort this like work well: different people, different project, different organization, different organizer?
I don't know all the participants of this particular project well enough to have any insight into their personal relationship with writing. It's possible that the online collaborative writing didn't work in part because of the organizational structure of the group. Although each group was semi-autonomous and had control over the content of its contribution to the final document, the organization had a specific 'director' (me) who was responsible for making the document coherent.
Perhaps the explanation for the lack of interest in editing the online document is the simple fact that it was easiest for everyone to send things to me, knowing that I would put all the pieces together.
Someday I would like to work on a truly interactive collaborative document. Perhaps the project would need to be shorter and simpler than the one I most recently worked on, so that each time a contributor accessed the document, it wasn't a monstrous task to digest all the recent edits and start in with new ones. And perhaps the project would have to involve an organizational structure in which everyone had an approximately equal role and responsibility for the final product (and/or no alternative but to work on the online document).
14 years ago
20 comments:
There's an even better solution, but your co-authors have to be computer geeks.
The better solution is to store the document in a revision control system, and use a document format that is amenable to revision control (e.g., latex or some other text-based format).
I figure that at this point, every computer scientist who is reading this post will be nodding their head, and everyone else will be sporting a lovely "huh?" expression. So perhaps I should explain.
See, revision control systems were initially designed for enabling a large team of software developers to collaboratively edit a giant pile of source code. The problem is this: you might be modifying that little piece over there, and I might be modifying the little piece over here, and we both need to be able to do our work without having to spend time coordinating or exchanging revisions. The larger the team, the more essential revision control becomes. Software folks have built powerful tools for revision control, which enables collaborative editing of text-y stuff. As long my changes don't conflict with your changes, we can separately and independently edit the source code, and the system will automatically merge our changes whenever we're ready for that.
This works really well for software development -- and it turns out, it works well for collaborating authoring of documents, too.
Unfortunately, there's a catch. The learning curve is substantial: you pretty much need to learn latex, as well as a revision control system. Computer scientists tend to already be familiar with both of these, for other reasons. However, other scientists may not have the same prior experience, so this might be less feasible for the rest of the world, sad to say.
That said, if you're ever lucky enough to have collaborators who are willing to learn latex and a revision control system (like, say, svn or git), give it a try! It rocks. It is so much better than the alternative. I can't imagine going back to what I was doing before.
(For the Word junkies: latex + revision control is a much better experience than Word + track changes.)
If you're curious to learn more, here is a blog post that discusses this kind kind of thing: http://www.freedom-to-tinker.com/blog/felten/developing-texts-we-develop-software
Maybe it's related to the fact that you're dealing with (I assume) older adults, who might not be quite so comfortable doing work online for whatever reason? I've been using Google Docs for the vast majority of my undergrad team projects/assignments these past three years, and it's great. Especially when you assign each person a colour (listed at the top of the document you're working on), and then all you have to do is skim through every colour that isn't your own to see the changes, and it's very obvious if someone has changed a section of what you've written.
From what I have noticed, Microsoft Office Groove may have been a good alternative. It works basically like a shared file but across the internet. I haven't had the opportunity to try it yet though it looked promising.
Papers I've worked on are still edited via emails prompting action, with only the latest draft of the paper either attached or linked.
Two factors come to mind:
1. There is no significant advantage to any online archive that tracked versions and such that we've discovered compared to Word tracking changes.
2. We want a living person to control the adoption of changes and prompt us. We don't all want to be notified of every change, for example, nor have the fifth author insert 10 self-references nor sensationalize the conclusions.
Only massive articles require so many changes and authors that a wiki is needed to bring the project under control.
What I like about GoogleDocs is that it archives the old versions, so you can go back and see the progression.
Another tool used in my lab is DropBox, which just allows us to share files easily, removing the need to email back and forth.
Great post. I've actually done a lot of online collaborative writing, of both papers and grants. I've done everything from the email-round-robin to simultaneously editing in Googledocs. My best writing was done in the following two circumstances:
1. I'm a prof at one institution, and I was working with a grad student at another. We both set aside time and worked simultaneously on the document. It helped tremendously to have a "writing buddy" and to have the other author I could ask questions to. "Can you think of how to rephrase this so that....", "I'm on page 36; I really don't like the fact that we aren't reprising this idea--I know we talked about it in 'Results' but I don't think the reader will remember it...what do you think". We used Google Docs as a whiteboard for trials "See what you think of this paragraph...does it work?" and for changes. One of us had the "master document" at any time, and would copy-paste from gdocs.
I'd say this got the paper written in a third the time, it was a better paper, and a hell of a lot more fun.
2. The other writing I've done is in a collaborative group of about nine scientists (the numbers have varied over time) writing papers and grants together. Here, we use Googledocs for the early stages, when we're just trying to get a draft on paper. This allows for a lot of simultaneous editing. We then move the draft to a commercial file-served that has a "check-out" feature, so one person has the doc at a time, and it's clear who has it. We use google calendar to "reserve time" with the doc.
This works *AMAZINGLY* well. The writing that comes out of this group is phenomenal, and the efficiency is staggering. Again, much faster, much better, and much more fun.
What's the catch? It's not technological, it's social, as you suggest in your post.
1) You all need to know each other and your strengths and weaknesses. Jamie is good at cutting down length, Shawn is an ideas person, but can't write concise prose, Anne knows the literature on topic X way better than anyone, and Conn is really good at thinking about overall structure.
2) You need to *trust* each other and trust yourselves. That means moving beyond track changes. If it needs changing, CHANGE IT. Don't wait for a second opinion (unless it's a radical change). Use comments to bring someone else's attention to something you can't fix, but if you can do it, move the project along and just make the paper better. The rest would agree with you anyway. It only bogs things down to clear every new semicolon with the group.
3) Everyone needs to be so comfortable with the technology that it doesn't feel like technology. This may not happen at the beginning of the project--they don't have to be technophiles, but you need people who aren't tech averse, or who don't want to learn a new piece of software in the middle of the writing process. The tools need to be transparent and not part of the problem
That's my $0.02, hope it's useful to someone else in FSP land!
Google has a new email client now, called Google wave (as an alternative to gmail). It has a very pleasant truly interactive collaboration system in place. Between two people, it is just like email; but when you add more people, everyone can see every change as soon as it is done, and if someone modifies the document, you don't need to upload/download a newer version each time. It also saves every move, so you can actually see who contributed what and play it like a video. I am not sure how it acts though, if you have an external non-google document.
The recent PhDs were just as reluctant as us old people to work with the online document. Age was not a factor.
When it comes to the point of editing a document, I like to print it out and mark my edits with (red) pen. I can't read 10 pages of text carefully for grammatical errors and typos on the screen; I need a printout.
If I do this, I need to be sure that the text is not going to change radically on me between the time I print it out and the time I type in my changes!
In another case, I might be changing some variable name throughout the document. I definitely need to make sure no one else is fiddling with the document at the same time. If I'm busy, this change could be taking place over a few days.
Once you get to the point where each author needs to "check out" the document for a few days at a time, you might as well just e-mail drafts around every few days.
I've written several papers in the context of online coursework, and our main problem with gdocs is that it doesn't have all the features necessary for APA format. We usually use chatting to define the outline and parcel out work, have a deadline for the individual portions then specify a time when we're all online to revise and comment. Granted, we are talking about papers in the <15pg category here.
That said, I think confidence is a huge issue in the process. Maybe the emailing back to you is a way of deflecting responsibility. That is, if a change gets committed, it is b/c *you* approved it. I'm not sure how to stop enabling this behavior - maybe y'all can do some trust falls?
I'm collaborating with some people on a document, and one of them took the initiative to set up a really good wiki that is easy to copy and paste the sections of the document into. It's actually gotten some use. However, it took a while, and a lot still gets circulated by email.
Some of my collaborators are very big on the "community-building" aspect of our project and they keep pestering everyone to communicate in the discussion forums rather than by email. However, conversations keep going to email.
Email isn't perfect, but it does seem to be a "killer app", or at least it kills off a lot of the others among academics. Given the choice, most academics keep going to email rather than wikis and such for their communication.
Less senior authors may have an aversion to directly edit the writing of more senior authors, so that may contribute to reluctance to use online collaboration tools. Or in the same vein, some may be hesitant to subject their less polished writing to immediate scrutiny.
I agree with the earlier comment that this is more of a social issue than technological.
On the topic of age, we've also noted that it doesn't correlate well with age. Actually, the most eager adopters in our experience seem to be recently minted associate professors, though individual variations are more important than time-in-career.
However there is a huge age effect. It's just that all professors are too old to notice it. It's those kids who are Web 2.0 native where you see the really big difference with respect to these tools. All of us faculty learned these tools as adults; it doesn't matter whether you learned them at 30 or 70.
The biggest factor is a comfort level with the new tools and with being in an early-on-the-learning-curve stage while trying to do something important when you're pressed for time. However, none of that matters unless the collaborators have a huge degree of social trust.
My guess is that it was discomfort with writing, and a belief that you could make it better. If I were collaborating with someone who I thought was a good or better writer, who was good at organizing information, I'd use the person as a crutch, rather than trying to make the cohesive changes myself.
So my guess is its not the technology, but the content that mattered, and the individuals writing the content.
My suggestion is to try a collaborative tool (like google docs) with one other collaborator, who thinks that they're basically as good a writer as you are and see how it works.
I have been experimenting with using Google Docs to maintain various documents for my lab (protocols, things to order, etc.). This has been extremely beneficial so far. I have also used Google Docs to draft a paper together with a student, and it worked very well. However, as soon as we shared with people a few years older who were less comfortable with online document editing, everything reverted to Word, sadly. I was left with the overall impression that online document editing can be far more efficient than e-mailing around copies of "Final version_FINAL_14.2", but the difficulty lies in getting everyone to buy into it.
By the way, there is a new version of Google Docs that has a new feature in which two people can "see" each other editing the same document. You have to enable the feature in the settings somewhere, but it is very cool.
I second the latex/source control system way! The only problem is you will have to convince your collaborators to commit their changes semi-often.
Otherwise, Google Wave seems to be a nice candidate - I'm waiting for a mature and usable latex widget...
I think the project has to be well-suited to shared documents for this to work. We have a few technical documents - detector manuals and a spread sheet with information on detector components - that work very well as shared documents. This is largely because the people who need them change on a nearly weekly basis and there have been major changes needed on a weekly basis. There's also a core group of people who have used these documents heavily and are committed to using shared documents.
I think there are problems when the "shared document" format is forced on a project that doesn't suit it and when not everyone really embraces the method. I've seen problems in hierarchical groups because people aren't willing to change things done by more senior people - even things like grammatical mistakes.
I put another vote in for using version control software. And while we're on the subject, I highly recommend using a distributed version control system such as git, and not a centralized version control system like subversion. The learning curve is similar to any other unix tool, and it has the advantage of making code review (or rather, proofreading) an absolute breeze. And if someone ever asks "What happened to those changes I made?" it's easy to track down exactly who changed which characters when.
I've had some experience with online collaboration tools, and one truly collaborative writing experience. Some colleagues and I wrote a grant proposal (that got funded!) where we used a commercial online document manager to pass versions around. This seemed to work well, although there were some hiccups when folks did not check the document back in.
The truly collaborative writing experience was just before such tools became available. My major prof (who wouldn't have used such things anyway) invited myself and another graduate student to co-author an invited paper. He decided he didn't want any data in it - just ideas. So he assigned us 20 topics, told us to write off the top of our head without references. Then we worked on integrating our brain-droppings into coherent ideas (or eliminating some topics). It was a really amazing experience, because the three of us trusted and respected each other's ideas and writing. I don't know how replicable that would be with a larger group, or one that did not have such strong ties, or electronically, for that matter. As a matter of fact, we undertook a similar effort a few years later, and while the paper was good, the experience was for some reason really not the same. Maybe some day social psychology will change this, but for now I wonder if it's just lightning in a bottle.
My estimate of what went wrong is this:
People are comfortable with certain ways of doing things, like editing documents. They don't want a big learning curve to get used to some other way of working. If you happen to have a group of collaborators for whom using Google docs is something that is compatible with their existing methods of working (writing), then it'll have a good chance of working well.
I think the group you were working with just happened to not find the Google doc convenient.
We find the same for students and group work. It doesn't work very well trying to force students to use one particular medium of collaboration; they get on better if they get to choose what works for them. If you try and force them, then you get rather perfunctory use of the medium.
Post a Comment