The Clunky Mechanics of Collaborative Writing

19 June 2013 by Tom Webb, posted in Uncategorized

Forget the myth of the lone genius: science is a collaborative enterprise, requiring cooperation within large teams of people. Often, this is both a joy and a necessity: many hands make light work in the lab or the field, and collaborations massively extend the scale of research questions we’re able to address. More and more, however, writing of papers, reports and funding applications is becoming collaborative too, and that’s seldom so pleasant; the best writing is personal, and writing by committee is difficult. There are counter-examples - the teams of writers beavering away on blockbuster US sitcoms spring to mind - but attempting to write something coherent when authors are scattered over multiple institutions, sometimes across many time zones, brings significant challenges. Although this post has been triggered by big collaborative writing project that's consuming my time recently, it would be inappropriate and hugely unfair to comment on some of the issues of content that plague all such enterprises; what I want to focus on instead is the actual mechanics of how we write. Some of the orthodox habits of academic collaborative writing seem incredibly frustrating, but I’m unsure of how to address them in a way that is accessible to all.

The first issue feels like it should be a non-issue, given that content is platform-independent: what software do you use to write? For almost everyone I’ve ever worked with, the answer is: MS Word. My view is that Word is fine for individual writing. Sure, ‘features’ like its habit of second-guessing your formatting choices or its eccentric decisions regarding wrapping text around figures are frustrating. But as a simple typewriter it’s OK, and although I’m trying to shift to Scrivener more for my own writing (using it now), I do still use Word daily. The commenting system in Word - comments and tracked changes - also works fine as long as the number of commenters is small. But in a team of 20 or so, and with a heavily edited document, it becomes very unwieldy and, more importantly, very unstable - I’ve lost so many annotations through crashes.

What are the alternatives? I’ve never really got on with Google Docs, or at least haven’t seen anything that would place it substantially above Word. I know papers are now being written with full version control in GitHub, but even the advocates of this approach admit that, for now, the technical barriers to entry are too high to expect all collaborators to use it. And to be honest, a 20-author document is always going to be unwieldy, regardless of the platform. Perhaps we just have to learn to live with this.

Then there is the profusion of files which again, inevitably results when lots of people are simultaneously working on different parts of a complex document. How do we track these? Emailing individual docs around is a recipe for disaster, so some kind of file sharing system needs to be adopted. I’m a big fan of dropbox, but not everyone is (some institutions actively block it, I’ve recently discovered). On this application we’ve been using MS SharePoint, which I have to admit I’m not a great fan of, perhaps because it’s just more of an effort than dropbox. Perhaps if we used its full features, e.g. signing out documents for editing, rather than downloading and re-uploading everything, it might have won me over. Upshot anyway is that I have both a SharePoint site and a Dropbox folder each containing close on 200 files, with many combinations of initials and dates appended, which must be suboptimal… (Incidentally, sticking a date at the end of a filename is useful, but if you do so yy-mm-dd format allows for the most logical sorting.)

That’s a lot of problems raised, with little in the way of solutions. So if you have any killer tips, do let me know! But I will finish with two more constructive points. First, I said I didn’t want to talk about content, but I think there is one thing worth emphasising: Nothing is Sacred. There is no place in a piece of collaborative writing for egos and intransigence. By all means argue your corner if you feel a coauthor has completely missed your point. But think: if your coauthor doesn’t get it, no chance that a reviewer will, or any other reader. So don’t just dismiss their concern; take their criticism on board, re-work your text, and get back to them. In this sense, collaboration is the first stage of peer review. (A related aside on comments and tracked-changes, in the context of multi-author documents: comments can be useful, if they take the form of “X please write two sentences on that thing you know about here…”. But before adding comments like “This needs more detail” or “This doesn’t work for me”, stop and think whether you could preempt your own comment by actually editing the document.)

Second, a couple formatting tips. Every proposal I’ve ever been involved with has ended up bouncing off the page limit, and so it’s useful to be able to make maximum use of available space. One tip I got from Twitter (whoever it was, thanks!) is to turn on automatic hyphenation in Word (Tools > Hyphenation…), which gains a surprising amount of space. Apart from that, I’m a bit wary of pushing font size and margins right to the limit, simply because confronting your reviewers with massive blocks of dense text is not going to do you any favours. The key then is to edit, edit, and edit again (see also the point above about nothing being sacred).

I take a strategic approach to this: any paragraph that ends with a line less than half full is ripe for reduction by one line, easily, simply by cutting unnecessary words and rephrasing. Be really harsh on repetition, verbiage, impressive-but-meaningless words, and repetition. (See what I did there?) Use short words like ‘use’, no need to utilise longer synonyms like ‘utilise’; this will help readability too. Funnily enough, this is an area where Twitter really helps, as it gets you used to fitting ideas into a strictly delimited space.

So anyway. I now open this to input from coauthors…


5 Responses to “The Clunky Mechanics of Collaborative Writing”

  1. Carl Boettiger (@cboettig) Reply | Permalink

    On the Github topic, you might enjoy taking a look at this example on an article written for Wired magazine: http://www.wired.com/wiredenterprise/2012/02/github-revisited/ The Wired writers were unfamiliar with github authoring before-hand, and just tried it out for fun, and comment on some of the cool advantages (with over 30 contributors) and the difficulties.

    In my opinion, anyone who can manage to submit a manuscript through most journal submission sites can manage to learn Github just fine.

    Github not perfect, but it's the best solution I've come across: I will sometimes even paste a collaborator's MS Word copy into a text file and let Git handle the merging with my copy. And being able to know who wrote each line can be fun later...

    • Tom Webb Reply | Permalink

      Thanks Carl, really interesting to have your view on the (lack of) technical hurdles in the way of doing things better. But I guess one of the things with Word is it's a massive basin of attraction - so even if it's not *much* effort to escape it, it is *some* effort, so most of us stay entrenched. Personally, however, I am really determined to climb out and plunge into Github soon! Going to read that wired article now…

    • Khalil A. Cassimally Reply | Permalink

      Thanks for pointing us to that Wired piece, Carl. I've never used Github before but from what I gather---and correct me if I'm wrong here---its main attraction is that it keeps track of changes made to a document (or code, etc).

      Limiting this discussion to documents here, what are its advantages over Google Docs? I do use GDocs as my primary writing app and it's also great for collaborative writing. Not only do changes appear in realtime but all changes are tracked and saved. These past "versions" can be accessed a later time if need be. My sole beef with GDocs however is that it may be a bit of a hassle to navigate through multiple "versions." That MS Word features track changes right in the document works great for editing. I wonder whether how Github goes about in this respect...

  2. David Lovell Reply | Permalink

    Thanks for this thoughtful article Tom. I reckon there are often two main writing phases which you could call "structural" and "stylistic" ... at least for a lot of academic writing. The "structural" bit is about the points that need to be made; the "stylistic" is about putting those points across in writing. Each demands a different approach and mindset. In a collaborative setting, one can easily descend into change-tracking hell if these two phases are comingled.

    As someone who began writing with vi and LaTeX, I find myself strangely fond of Word's change tracking, but only, ONLY, for putting the polish on content that is structurally sound and roughly in the right stylistic ballpark.

    I'm not sure what tools are appropriate for getting a workable structure in place collaboratively, but I do think that it helps to create a terse hierarchical outline (a.k.a. structured skeleton), the elements of which can be moved about until everyone is pretty happy with the points that are being made, and their order.

    That structure should give the authors a sense of what needs to be said and where so that (ideally) the magnum opus can be divided and conquered. (With a sprinkle of change tracking at the end - ideally deletions - to ensure that the text is undiluted by extraneous words and turns of phrase.)

    • Tom Webb Reply | Permalink

      Thanks David! The distinction between 'structural' and 'stylistic' phases is a really useful one. One of the things Scrivener does well is to enable you to separate these out, so you can edit the structure independent of the content. Great for individuals writing their magnum opus, but not really designed for collaboration. But for a big, collaborative doc I agree: get the structure down first, then at least everyone is pulling in the same direction!

Leave a Reply


× nine = 63