This year I need to work with a rather large group of people on a lengthy and complex document to which we will each contribute at various times as our schedules permit. I have done large group-write projects before, and such things typically involve some logistical issues involving who is working on what draft when and what kind of editing notations each person uses and how often the drafts are distributed and whether the drafts are distributed to everyone or a subset of the group and so on. It can get confusing and complicated and annoying.
In fact, I am typically not the one who is annoyed but am the one being annoying because, although I try not to go too crazy with producing multiple drafts, if I've been working on the document, it's easier if the next person to work on the document works from the latest draft instead of an older version.
So, to improve the experience of writing something with a large group, I decided to dive into the wonderful world of wiki webs. With a wiki, everyone in the group can access the text whenever they want, and the text is always the latest draft.
Is that the perfect solution or what?
In fact, it hasn't been the perfect solution, but overall I'd say it has been significantly better than the alternative. The lack of perfectness stems from a few issues related to wiki creation and use:
1. The technical aspects of setting up a wiki, at least using the system preferred by my university, are BIZARRE. I have never seen so much jargon in my life, and that's saying something considering how much jargon is in the document my colleagues and I are writing. And forget using the help utility -- the one I used consisted of layers and layers of non-intuitive jargon. I finally had to ask a wiki-experienced youngster (an assistant professor) to help me get started.
2. The wiki philosophy is one of openness and freedom for anyone to edit text any time, so if you try to put some access controls on a wiki, you get a lecture about it before being allowed to set the controls. OK, I get the philosophy, but even Wikipedia locks some entries and gives different levels of editing access. What if I don't want anyone in the world to be able to view my text? I don't care so much about the editing (all versions are saved and the editing can be tracked), but let me have the freedom to be mildly paranoid about research-related documents without giving me a lecture about how I am violating the essence of wikiness.
3. There are some strange glitches related to attaching and deleting and updating files, and the relationship of text and images. I have found myself uploading frequent pdfs, in case anyone wants to see what the document 'really' looks like.
Those are just strange little wiki-glitches. The most surprising thing to me is..
4. .. how reluctant so many of my colleagues have been to add/edit text using the wiki. I set the wiki up, so it's just sitting there waiting to be edited; no one else has to deal with the bizarre technical aspects of the wiki.
These colleagues have no problem writing. In fact, they send me frequent drafts and text fragments by email, but they are shy about putting their writing directly on the wiki for everyone in the group to see. I get emails saying "Can you please look this over first and tell me if you think it is ready to go on the wiki page?" or "Can we discuss this and come up with a better version before putting it on the wiki page?".
So that's what we do. It is still much better than the non-wiki way of doing things. The latest draft is always available for anyone to see, and I have found the process of group-writing to be much more efficient with the wiki, even if not everyone is on board with the wiki way of writing.
Perhaps with time people will become less shy about going directly to the wiki without involving me first, but perhaps I am facilitating their reluctance by letting them use me as an intermediate step. I will have to think about that some more, and perhaps do some experiments on selected individuals. In the meantime, it is rather sobering to see that the last 39 drafts were edited by me because I seem to be one of the only ones who is not wikiphobic.
14 years ago
33 comments:
We had to get our sys admin to set up the wikis, but only a few have been reluctant to display their writing.
In this case I vote for immersion, don't give them a crutch by posting material for them. Just make sure some technical expertise is at hand when they first jump in so they are not exposed to the possibility of leaving large gaffs as their first efforts or wasting time puzzling over manuals.
I'm surprised how few scientists have taken a stab at cleaning up their specialties on Wikipedia - it used to be simple to improve, and is so widely used. We're supposed to be eager to accurately educate the public even if our names are not prominent and it doesn't show up on our CV.
I gave up on editing science pages in Wikipedia when some crazed individual kept taking my correct (says me) text and changing it to fit some insane ideas. He/she was relentless about changing everything back, so I quit trying. Reader beware etc.
I'd suggest using Google Docs for any collaborative system. It's worked fine the two times I've tried it and
allows a document to be edited/changed by multiple authors, while allowing you to keep track of all earlier versions. Any reason why this wasn't the first choice?
There's virtually no setup involved.
I am part of a working group which was funded to build wiki pages and work on google maps. We meet for the first time this summer. I am soooo not volunteering for wikihell. I'm the youngest of the group (80% old fogies) and I just now, right this moment, forgot everything I knew about how to use wiki. Yep gone. poof. My crystal ball predicts someone else will have a heart attack.
It took three frustrating draft submissions when I was co-writing last to realize that my co-writer didn't like or use track changes. Instead, they simply updated old drafts of theirs with the track change comments I'd left in red, without realizing I had done copious proof-reading (three times over) in the text itself without clogging up the page with tiny "user added a comma" notes to make it easier on *them*. Arg! I have a feeling if I were to set up a wiki, I would have to give at least 3 seminars to my lab to teach everyone how to use it and then no one would.
But as obscure Canadian politician John Nunziata would say, I'm not bitter :)
Why not use some version control system like subversion or CVS? I guess this does require that you use something like latex or plain text, and not word.
But if you split a large document into a file per section, this is especially trivial to concurrently edit. And even if you edit the same section, the software can typically figure out the merge order (unless it is the very same lines)...
As someone who has done a lot of grant writing with many "Web 2.0" tools of this type, I have to give three full-throated cheers for shared text documents. It makes me wonder how we ever wrote grants collaboratively before. As for your hesitant colleagues, they'll get the hang of it. Just keep reiterating that every time they make a change, the old draft is saved, so it can always be effortlessly changed back. As for Wikipedia, that is an unfortunate feature when it happens to a competent writer such as yourself. The good news is that is it this "easy reversion" which makes Wikipedia quite resistant to vandalism. It takes 2 hours to change an article with malice...2 seconds to revert it.
one group collaboration tool that has worked for me is Wiggio. The version control is sort of ad hoc, but it's there!
I had a similar experience to FSP. I submitted several corrections all of which were removed without explanation. I don't mind an editor catching an improper edit and deleting it with an explanation, but I don't have time to engage in a game of "guess where the mistake is" ---assuming there was one to begin with.
Hi FSP,
I have been using wikis for quite a while, but more recently, I tend to use Google Docs for collaborative writing.
It is better in the sense that editing is much easier and thus many wiki-reluctant people tend to be easier to convince. I also prefer the way simultaneous collaboration is possible.
There are some allegedly friendly wiki softwares out there, and I think people use them for projects just like you've described, FSP. But they do cost money. And I haven't stumbled across a review of them yet.
I want a wiki software that will e-mail me automatically every time a given page gets edited. That way I can ignore the wiki until I get an e-mail to go look at it.
Wiki's are great. I've worked a lot on adding scientific content to Wikipedia and have always found it to be a positive experience. I think their use is not so good for collaborative research writing - particularly papers and grants. For this we've favoured using GoogleDocs. There's still no support for reference management or equations but for getting raw text and images together it has proved very useful.
I think online writing collaboration is fantastic and works quite well once the initial "shyness" wears off. Have you tried google documents for this? It is easier to control access (closed by default) and is a word processor. I'm not that familiar with wiki's so I don't know how word-processing friendly they are.
I guess in a wiki you could put *why* you thought the changes were warranted. That could be useful. . .hmm.
I always figure that if google vaporizes I have bigger problems than loosing my docs. . .like the end of the world. (I do back up anyways)
This whole wiki discussion is a little foreign to me. Two words: FTP site! You leave all your working documents in one place, and if you try to work on it while someone else has it open, you have the option of saving a new copy or getting a notification when they're done. If you're using word, put it in tracked-changes mode.
You should check out EtherPad.
Although it's more geared towards realtime collaboration, you could use it in a wiki sort of way, without all the hassles of settings things up.
In the academy, many people are reluctant to put out any text without it being repeatedly vetted. Wikis operate on a publish-then-correct model, and even thought the "publication" is only to the local wiki users, it can go against some pretty old instincts for academics and scientists.
Have you ever used Google docs? I haven't used their text editor, but some of my students use Google's powerpoint clone when they need to work together on a presentation, and that one seems to work fairly well. My impression is that it's a fairly easy jump from Microsoft products to Google docs, that Google docs let people all work on the same document (and always see the most recent version), and that you get to decide who can work with it. I think, if I were working on the sort of report you're discussing, I would try that before trying to make a committee learn to use a wiki.
I am in similar situation where I am coauthoring a book. I am trying office live instead. You can upload and download latest version of the document to the common office live space directly from Microsoft-word. It works well with small document size but crashes continuously when the file size is big (~8MB) which is inevitable with multiple figures. I will try wiki if that works better.
I have used multi-file LaTeX documents with automated build systems and revision control for collaborative editing exactly once.
It was a pretty good experience, but all the authors were already familiar with the tool chain...
Automated merging is *so* nice when it works, and when it doesn't you're no worse off that you were before.
A wiki is probably easier to learn.
Wow, setting up a wiki at my university was very easy. I could also control access quite easily through the wiki itself (LocalSettings.php), or through certificates-based control to the wiki's location on our university's file system. My university also has a very active student-run organization that provides help, feedback, assistance, and tips. I was even able to install wiki extensions, most notably one that let me use LaTeX-style equation entry. Easy!
I hope whoever is lecturing you gets the business from you or from someone in a similar situation sometime soon. Was this from people in the FSPU IT department? Can you imagine a corporate IT guy giving a lecture to a corporate executive who wanted to start a company-internal wiki?
Gotta say, I never thought of any of these methods before. Wow, this opens up a whole new world of possibilities. Thank you.
Sounds like almost all of your problems are the result of less-than-great wiki software. You might want to check out google sites or PB wiki. These are both freeware solutions that should have all the functionality you need and maybe less annoying glitches.
As for the hesitancy, I second. It really surprises me how hesitant people are to use the online tools. I have the same experience with google docs and group webpages. I think it is mostly psychological. Most people don't comment on blogs and such so aren't use to scribbling freely all over webpages.
In your case, it might help if your wiki has an automatic draft archiving system. I.e., you never lose older versions and can always go back and see older drafts. Or perhaps if you had some kind of "approve changes" feature where people could add there text, but they new it had to be reviewed before it could really added. MS word has some pretty sophisticated track changes features. Something like that in a wiki may help people feel less shy about altering the text.
hahaha. I have tried this (Google docs, LaTex with version control, etc.) with my collaborators, but the profs are all much older and way too mystified by being asked to use new technology. They refused.
They think using Microsoft Word is better than having to learn something slightly different. And acted like I am insane for even suggesting it.
And you wonder why I think these people should be encouraged to retire?
Thanks for posting on this! I've just entered the world of co-authored papers, and coordinating drafts is much more difficult than I expected. My co-authors insisted on using Word, so we had all these drafts floating around, and one person kept forgetting which was the latest draft, so he would make all these changes to an obsolete draft, and then I'd have to go back and remake all my changes on his draft. We finally ended up sitting around one computer, going through the document line by line and merging our changes together. It was just about the most tedious 2 hours I've ever spent! Next time I'll insist on using one of these alternatives.
latex + subversion = bliss
I tried setting up a wiki for a student project internally and it turned out to be such a nightmare that I used pbwiki in the end - very easy to set up and have student editing access (except many students forgot their new username and password for it). It is something I will try again next time, now I realise they need substantially more supervision than I'd expected.
For editing papers collaboratively, however, I, like many of the commenters, use googledocs - its been extremely useful, especially where one collaborator's harddrives broke down, killing their local files - but everything was still online! :> The word-like interface is simple enough for a professor to use, they just need to remember to log in. ;)
I was told at work NOT to edit the organisation's wikipedia page - cos it would be seen in the press as trying to 'censor' criticism.
Seemed odd to me.
Google Docs is an attractive idea, Gautan, but did you read the T&C before checking the 'I accept' box? There are some serious problems about IPR.
A further alternative that I forgot to mention was dropbox - http://www.getdropbox.com
I think it has some sort of version control (at least when two of us edited a file at once it did save them out separately, and I think you can do more sophisticated things) and it's been super useful for having an accessible source of any type of file (eg word). There might be IPR rights as well, however, as Bob mentioned. (I could say a bit about this and science, but my opinions are too long for a polite comment :)
Personally, backpack and basecamp are the products I go to when things need to get done with a group. Well, also when I need to get things done on my own. It's lovely how they really considered what users want and the options they give you. Like comparing several drafts of a document against eachother...
I like the latex + subversion solution, but the last time I used it for group writing, my co-writers refused to invest any time in understanding how to use subversion, which resulted in no end of difficulties (with them messing up the repositories and me having to fix it). Also, they rarely uploaded new versions and refused to learn how to use the difference and merge tools. So from their point of view, the version control appeared worse than useless, I ended up doing a lot of extra work trying to fix their technical mistakes and explain basic features to them, and in the end, we were all duly frustrated.
"The wiki philosophy is one of openness and freedom for anyone to edit text any time, so if you try to put some access controls on a wiki, you get a lecture about it before being allowed to set the controls."
This is because so many people overengineer their editorial control system, making it into some Soviet-style bureaucracy.
I've seen people who were thinking of setting up a wiki with a restricted readership and a fairly technical focus, discussing of an editorial committee and safeguards in case there was "abuse".
I've also seen people working in institutions where Web every page published on the Web needs approval from hierarchy. Needless to say, apart from pages filled by public relation staff (the usual bland, stereotyped and information-free PR stuff), they do not publish anything. Researchers there sometimes get their research pages hosted elsewhere...
With respect to collaborative writing: we used LaTeX + subversion to write a grant proposal.
The problem is that some of the (older) members of the team did not want to figure out how to use subversion, so they kept on sending "revised versions".
It soon became hellish, because they never specified on which "base versions" they had based their "revised versions".
Basically, there are three ways out of there:
* Either divide the text into sections, stored in different files, and only one person has write access to each file. The problem is that this prevents fixing even typos in other files.
* Either implement a "token" system - only the person with the token can write. This slows down everybody.
* Either you force people to learn to type "svn up", which is not rocket science.
Post a Comment