Tom Boellstorff, Bonnie Nardi, Celia Pearce, T. Taylor
In this article we detail primarily online collaborative authoring practices we have found to be of practical and conceptual interest. In 2012, the four of us published Ethnography and Virtual Worlds: A Handbook of Method . Prior to composing this text, all of us had written book-length ethnographies of virtual worlds and for some time had frequently been asked, “How did you do it?” The Handbook allowed us to synthesize and draw out principles and practices for effective ethnographic research in virtual worlds, beyond the more truncated methodological discussions that appeared in our individual work [2,3,4,5].
In the wake of the Handbook’s publication, we encountered a new question: “How did you write a book with four authors?” This query typically emerged when the person realized the Handbook had been written as an entirely collaborative document, with a single authorial voice. Before settling on this format, we considered several other options, including producing an edited volume and composing chapters individually authored by each of us. We eventually decided these approaches would be inadequate given the broader shared themes, examples, and practical guidance we sought to provide. We instead chose to develop a shared narrative, writing the book in a single voice. Although all four of us had co-authored publications prior to the Handbook, none of us had co-authored a book-length text with so many collaborators.
The logistics of the collaboration were challenging from the outset. Because of our differing disciplinary backgrounds and varied academic homes (anthropology, computer science, media studies, and sociology), not to mention our locations at the time (Irvine, Atlanta, and Copenhagen), we had our work cut out for us. We had 80,000 words to jointly produce, for which our goal was achieving a single voice. We needed tools that would enable us to write, comment, rewrite, edit, discuss, and reach consensus.
We achieved our goal with a mix of synchronous and asynchronous collaboration methods. Aside from a small number of face-to-face meetings, we spent many hours in email and Skype discussing how best to present the principles of ethnographic research, how to clear up misconceptions regarding its scope and value, and how to reach a wide audience. Working toward these goals meant deciding which topics were most important (staying within our self-imposed mandate of a short “handbook”), refining a terminology for multiple constituencies, and balancing details about everyday ethnographic practice with big-picture issues regarding the place of ethnography in social inquiry. Though we at times had intense discussions over particular points, the process of working through our different perspectives and coming to consensus, crafting text that resonated for all authors such that each felt that they could stand behind the work, proved incredibly valuable.
The payoff was significant, particularly in drawing illustrative examples from our varied projects, as well as integrating diverse interdisciplinary literatures and perspectives. Here we discuss the means by which, after a good deal of trial and error, we found effective procedures for our collaboration. Our hope is that an explanation of our methods will be useful to other scholars and to software designers developing collaborative writing tools.
From the beginning, we knew we wanted to emphasize that “ethnography is a flexible, responsive methodology, sensitive to emergent phenomena and emergent research questions” . In retrospect, it is not surprising that what ended up being a highly effective set of collaborative practices for writing the Handbook also emerged through flexibility and responsiveness.
One common way for scholars to coauthor a piece of writing is to email a draft back and forth. Many applications, in particular Microsoft Word, have functions for commenting and tracking changes that can further facilitate this kind of collaboration. For reasons of familiarity and perceived convenience, we began by using Word for the early stages of writing, breaking into pairs to write initial drafts of chapter sections. Because sections were more thematically focused than whole chapters, a pair of authors could easily work up an initial draft by exchanging a Word document, then utilizing the in-program editing and commenting functions. Sharing a Word document required the team to specify which member “owned” it at any given time. One upside to this method is that it can put firm deadlines on whoever is “holding” the document to turn it around to his or her partner. This method can also provide a welcome pause for a section that has been overly edited and lost authorial coherence, allowing one team member to try to sort out a piece of text.
However, it soon became obvious that this approach would be unwieldy for the Handbook. It would mean that only one of the four authors could work on a section of text at any given time, which would have greatly slowed the pace of writing. Relying on a Word file would have made synchronous collaboration impossible, since if one author proposed a change while on a conference call, the other three would have had to manually type in the edit on their respective versions of the document. It also created a potential nightmare for version control. Once it was time to invite the other two authors into the conversation, we therefore needed a different procedure.
We moved to working with a master document in Google Docs (part of the Google Drive service). To be able to search for strings of words easily and weed out repetitive phrasing, as well as to move blocks of text as needed, we added each chapter section to a single document that grew as the manuscript progressed. A table of contents with anchors at the start of the document easily allowed anyone to jump to a section of the text. At the time we wrote the Handbook, a single file within Google Docs could be a maximum of about a million characters, so we had to split the manuscript into two documents. Having only two documents (rather than, say, a separate one for each chapter) facilitated searches and backing up drafts for safekeeping. (Despite the reliability we experienced with Google Docs, we backed up frequently to preserve a version of the document on other devices.)
Once a draft was uploaded to Google Docs, we entered a two-phase process of asynchronous and synchronous collaboration. In the asynchronous phase, we would individually log in and read through the draft. We had agreed that we could make small grammatical changes “silently,” but that any substantive alterations necessitated confirmation from the other three authors. Google Docs offered a tool for both asynchronous and synchronous collaboration that was free, private, and reliable (it auto-saved every few seconds, and we never lost data or had difficulty reaching the site, though it could be slow to load). Instead of the Track Changes feature of Word, it had a commenting feature that allowed one person to post an initial comment and others to add responses within that comment box, creating a thread of commentary, identified with each author. Individual comments could be edited by their author; the entire comment thread could be deleted by anyone by pressing a Resolve button. Because the document was hosted online, multiple authors could work inside it at once, which was particularly helpful during synchronous team sessions.
Our breakthrough occurred when we realized that rather than propose an edit in a comment box, we could make the proposed edit in the text and paste the old version in a comment box. As the other three authors logged in, they could add a response along the lines of “fine with me!” to indicate agreement. We developed a code for each author to indicate when someone had not yet confirmed a change: TFIX, BFIX, CFIX, and TLFIX (based on our first names; see Figure 1).
By searching for those unique terms, an author could find proposed edits they had not yet “fixed.” When encountering a proposed change the other authors had already confirmed, we used a principle we dubbed “last person out shuts the door”the fourth author would use the Resolve button to delete the entire comment thread. Since we had placed the new text in the main document, deleting the comment thread removed the older, superseded version of the text. If an author disagreed with a proposed edit, that author could leave a more substantial query in the comment thread. This would draw a response from the author who proposed the edit as well as the other authors. Authors could follow one another’s activities by electing to have time-stamped comments forwarded to their email accounts.
Though these forms of asynchronous exchange often led to a resolution, we found that some comment threads quickly grew to an unwieldy length and were ill-suited for complex discussions. We therefore developed a protocol in which any author could simply insert the word “SKYPE” in a comment thread. This would freeze the thread (and associated text) so that no further changes would be made, marking the proposed edit as requiring a synchronous discussionthe second phase of our collective process.
While we used asynchronous collaboration primarily during the early phases of composing the manuscript, we did return to asynchronous collaborating after the synchronous phase, in the final stages of writing. In the couple of weeks before submitting the manuscript to the publisher, we entered a phase we termed lockdown, when none of us were to make any further edits to the Google Doc. This allowed us to individually download the full draft of the handbook, print it out, and look it over carefully for overall flow. Here, as elsewhere in our collaboration, technologies helped enforce a social processnot in a deterministic manner, but as a toolkit of protocols reworked as part of the collaboration itself.
The asynchronous procedure described here allowed us to propose, confirm, and implement edits without the challenge of a difficult-to-organize four-way conversation. However, for a substantial number of proposed changes, the concerns were significant enough that a synchronous conversation was needed. These conversations were very important to our process, unlike what is reported in some of the literature on collaborative writing. For example, in an interview study of collaborative writing projects, Jeremy Birnholtz and Steven Ibara noted that “[Study participants] often did not schedule face-to-face or other meetings to discuss the details of specific edits or changes” . The authors reported that participants worked within the writing medium itself, using, for example, commenting tools. Our process was slightly different because our goal was to achieve a unified voice for the book.
The way Google Docs handled multiple authors turned out to be central to our collaboration. The presence of an author was indicated to others at the top of their screens as a “viewer” with a color-coded box that, if hovered over, would indicate the person’s name. Clicking on that box allowed one to jump to wherever the named author was in the document. We discovered this feature unexpectedly and found it to be a powerful collaboration tool. Anyone editing the document also appeared as a color-coded cursor indicating his or her location. If an author highlighted text, the other authors could see the highlighting. Any text added or deleted was visible in real time to other authors who were logged in, and a text chat window on the right side of the screen allowed authors to communicate as they worked.
Using this system typically involved someone entering the document, and, seeing a fellow author online, initiating a conversation in the chat window. Each could go to the section of the document under discussion and communicate any concerns. This was useful for quick fixes or queries (or even just hellos and encouragements!), while more substantial discussions emerging from long comment threads required voice communication. For these conversations, we would log into the Google Doc while simultaneously entering a group call on Skype. During the call, we would search for proposed edits marked with “SKYPE.” With all of us in the document simultaneously, we could see our coauthors’ colored cursors and jump collectively to a place in the document where there was an unresolved proposed edit (see Figure 2).
Often one author would verbally propose an edit while a second author would quickly type in what was being said, with a third close behind correcting errors. Upon reaching a decision, we could then immediately resolve the comment thread. We estimate we spent a total of about 150 hours of collective Skyping going over edits in this fashion, but are certain that without the earlier stage of asynchronous collaboration, the time needed for conversations would have been far greater.
We did not fail to notice that when together in the Google Doc, our collaboration resembled a simple text-based virtual world, with color-coded cursors we came to humorously term our avatars, moving across a “geography” of text. Like a virtual world, the document had a persistence as we individually entered and left. It was this feeling of a living world that made using an online document so different from circulating a Word file. We could inhabit the text together or visit it on our own and see evidence of others’ activity. These qualities greatly facilitate collaborative writing when more than two coauthors are involved. It is feasible to circulate documents via email or Dropbox with a single coauthor and discuss them on the phone or Skype, but as additional coauthors are added to a team, this becomes cumbersome. The shared document provided a dynamic venue for collaboration.
We can draw several brief concluding insights from our collaboration. First, every stage was marked by the use of multiple technologies, mirroring how game and virtual-world communities collaborate. While in theory it is possible to imagine a single platform that serves the needs of a collaborative project, our experience is that collaborators end up building a toolkit of various applications available at the time, based on the emergent needs of the team and the project at hand. Second, while particular programs offered important varying possibilities of use and engagement, the principles and methods we developed were central to the success of the process. Overall, our collaborative authoring practices were central to the Handbook’s success. They allowed a unique collective writing voice to emerge that harmonized with the powerful common ground we had forged in terms of our claims, insights, and goals.
Tom Boellstorff is a professor in the Department of Anthropology at the University of California, Irvine. From 2007 to 2012 he was editor-in-chief of American Anthropologist. His publications include The Gay Archipelago, A Coincidence of Desires, Coming of Age in Second Life, and Ethnography and Virtual Worlds: a Handbook of Method (with B. Nardi, C. Pearce, and T. L. Taylor).
Bonnie Nardi is a professor in the Donald Bren School of Information and Computer Sciences at the University of California, Irvine. She is the author of My Life as a Night Elf Priest: An Anthropological Account of World of Warcraft and Ethnography and Virtual Worlds: A Handbook of Method (as coauthor).
Celia Pearce is an associate professor of digital media at Georgia Tech. Her writings include Communities of Play: Emergent Cultures in Multiplayer Games and Virtual Worlds, and Ethnography and Virtual Worlds: A Handbook of Method (as coauthor). She is also a cofounder and festival chair for IndieCade (www.indiecade.com).
T. L. Taylor is an associate professor in comparative media studies at MIT. She is the author of Play Between Worlds: Exploring Online Game Culture, Raising the Stakes: E-Sports and the Professionalization of Computer Gaming, and Ethnography and Virtual Worlds: A Handbook of Method (as coauthor).
©2013 ACM 1072-5220/13/09 $15.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2013 ACM, Inc.