Perhaps you’ll recognize this pattern: A committee of any size larger than 2 needs to consider a document, and can’t do so during a regularly scheduled meeting, and scheduling a meeting is hard to do anyways. Then comes the following Sentence of Doom: “I’ll circulate the document for comments via e-mail.”
The impulse is understandable: Everyone’s on e-mail. It’s a text-based medium, and so it’s almost natural for people to bang out a quick reply. Those things should drive up participation, and increase buy-in for the document’s contents. Hey–it’s like crowd-sourcing, almost!
Except it’s not. There are numerous problems:
- The document will fork, or even splinter. Competing versions start to circulate, and all of a sudden it’s hard to tell what’s under discussion.
- There’s a strong first-mover bias. Everyone’s on e-mail, it’s true, but not everyone is on e-mail on the same schedule. The discussion is framed, though, by the first people to reply. Fortunately, it’s not quite as bad as YouTube comments, but there’s something disquieting about seeing 10 e-mails in a thread you’re just coming around to.
- The fact that everyone’s on e-mail is a problem as well as a benefit: If something shows up in my inbox with an invitation for comments, I’ll probably comment on it–even if I haven’t been paying as much attention to the issue as I should.
A much more reasonable way to solicit feedback is to post the document to a wiki or to Google Docs and to share it with members of the committee. There are real advantages:
- There’s one document, which people can edit directly. Everyone can see what’s under discussion. Google Docs, and most wikis, preserve the previous versions, so it’s easy to revert back.
- It alleviates the first-mover problem, because people just focus on the one document, rather than the cascade of e-mails.
- Because you’re inviting people to participate in the process, rather than pushing the document out to everyone, it’s likely that only people who genuinely care will bother to click the link. That means your committee can create the best document possible, and then use that as the basis for building consensus or legitimacy.
As usual, the CommonCraft people explain this process very clearly:
Since Google Docs, and wikis such as PBWorks, use WYSIWYG interfaces much like Word or various e-mail clients, there’s not much to learn.
In 2010, let’s try to make group work a little more convenient!
Related reading:
- “Revision isn’t cleaning up after the party: it is the party“
- “Drafting and revising documents” on PBWorks
- “3 Ways to Edit Documents Collaboratively“
- Advanced collaborative editing: Google Wave
Image by flickr user bionicteaching / CC licensed
8 Comments
There’s also EtherPad, which allows mulitple users to edit in real time, with color-coded authors. Pretty simple and very clear, as to who’s doing what damage to my subtle and wonderful text.
Free, with security provided by a randomized URL, or pretty cheap, with password protection. (Password protection free for three users.)
At http://www.etherpad.com
I concede that those “mulitple” damage-doers might just be correcting my spelling. . . .
Thanks for this, Jason. I used this YouTube video to introduce GoogleDocs to my first-year students earlier this semester when they were doing a collaborative project. They took to the program like fish out of water.
What they found was that using a collaborative program took the pressure off of one student to be the “one in charge.” Using GoogleDocs made everyone equally responsible for the work they produced.
If you had been at the meeting, you could’ve stopped the madness BEFORE it started!
Dude, if I only had one chain of e-mail in my inbox that invited comments on a draft, I’d count myself the happiest professor in Connecticut!
In the particle physics word we use LaTex to typeset our documents, thus any collaborative editing or revision is usually done via SVN (or in the past CVS). The LaTeX+SVN works well for the tech-savy – thus most of us – but is definitively a problem when one of the editors or authors is a older professor
LyX can help newcomers to the LaTeX world, particularly if you can get them an installed and configured setup on a USB drive or the like. LyX plus Subversion (or git, or any other decent distributed change-management system) does definitely require more initial effort than point-and-shrug applications like Google Docs, but it’s also far easier to customize and enhance, since it’s not a black box.
And Google Docs is rather buggy; I’ve been using it for a few group projects over the past few months and we’ve seen numerous problems. The features are also rather limited, though in some ways that’s a blessing, since during the collaborative writing process you generally don’t want people tussling over typefaces.
But whatever the method, Jason’s point is a good one. Using email for collaborative work on the same document is terribly inefficient and fragile. There are much better tools – just pick your poison.
According to the most recent NSSE survey results, about 30% of students use collaborating writing applications like Google Docs, but faculty members are largely unaware of their existence. This is all the more reason for faculty members to start working with these kinds of apps in their scholarly and administrative work.
I can speak from my own experience that when I’ve tried to invite colleagues to collaborate on a Google Doc, many times the application is so alien to them that they give up. For those of you who have successfully encouraged colleagues to start using Google Docs or similar apps, how have you gotten them over the initial barriers to adoption?
3 Trackbacks
[...] This post was mentioned on Twitter by Ethan Watrall, ProfHacker. ProfHacker said: New at ProfHacker: "E-mail is not a tool for revision," by @jbj: http://bit.ly/2YpYCL [...]
Social comments and analytics for this post…
This post was mentioned on Twitter by ProfHacker: New at ProfHacker: “E-mail is not a tool for revision,” by @jbj: http://bit.ly/2YpYCL...
[...] Why you shouldn’t use email for revisions Here’s an interesting post from Professor Hacker demonstrating the flaws of using email as a tactic for group revisions. As a student who does a lot of collaborative projects, I would certainly have to agree with their conclusion. [...]