Collaborative Long Form Writing
Writing our book, Service Design: from insight to implementation was not only a long writing task, but also a logistical challenge. All three authors were in different countries. Ben is in London, Lavrans in Oslo and I travel back and forth between Offenburg and Luzern. Added to that, our Publisher is based in New York and our Editor, JoAnn Simony, is in Phoenix, Arizona. That required a lot of document wrangling. So, what did we learn?
Structure, style and sculpting
With three people working on a text, one of whom is Norwegian (even though his English is excellent), one would imagine the style of the writing would constantly shift around. Readers will have to be the ultimate judge of this, but I was surprised how little this actually happened. It helped that I did most of the editing and re-writing of the manuscript (see document wrangling below), because a large part of that was about making the writing flow and hang together.
Initially, we planned to get the first part written, re-written and polished and then move onto the next, but we found this was stalling the process. Instead, we the content into to sections and writing parts of it individually and then I brought them together. This showed up where there were gaps between sections, parts that needed finishing and where we needed to restructure. Often it was an iterative process (we are all designers, after all) and the first draft acted like the raw clay of a sculpture in an initial form and then it was gradually given shape and re-shaped by each of us.
I am a big fan and have long experience in remote working (I first started doing this in the mid-90s). The tools available these days make that process much, much easier, but there are still times when we needed to get together in a room. The most important time was near the end of the process. We had a lot of the book written, but had a real struggle with the structure. We really didn’t want to have the insurance company case study in its entirety at the beginning because we thought it might bore people. Our plan was to use that case study in sections, illustrating each part of the service design process. In reality, that process is much more parallel than linear, but books are linear. So we got together and my house in Germany for a weekend and worked on the structure by putting it all up on the wall (yes, with Post-It notes) and sketching out structures:
This was so much easier to do face-to-face than remotely and that kind of process is still the Holy Grail of remote collaboration tools. It would be interesting to see whether we could have done this with a web service like the newly launched Stormboard, but sometimes seeing someone’s energy or unsure/thinking/disappointed facial expression guides the process enormously.
Finally, we had a structure and we then wrestled this into the final manuscript that still went through several re-structures with JoAnn and Lou before it ended up as the published version.
Finishing a manuscript is really only half the work of actually creating a book. We had several rounds of editing, expanding and re-structuring thanks to very helpful feedback from our external reviewers and our Editor not to mention input from Lou Rosenfeld. It takes a lot of time to integrate all these changes, re-write sections, clarify parts, check references and find or create the right images and write captions. It is what I call the “sweeping up” part of the writing process and on a long-form project, it always takes longer than you expect. I call it sweeping up, because it feels like the main part of the process is a big sculptural or engineering effort, but at the end you are left with lots of small pieces on the floor that have to be dealt with, swept up and either integrated or put away. The paradox with three authors is that things can take longer rather than being three times as fast. Multiple authors create dependencies.
When I have my academic hat on, I’m careful to gather and format my references as I write. Tracking them all down after writing is a nightmare (note to students: get into the habit of doing this as you write!). The same goes for images though and we were not quite prepared for the effort it would take to track down high resolution versions of our own images. These were often images we had used in presentations over the years and simple copied from file to file and never had to find print-quality versions. They were not on the machines, servers or in the folders that we thought they were. Others were from commercial projects and whilst we could use them in private presentations, we could not use them in the books due to non-disclosure agreements or because we could not publish pictures of the interviewees in the research photos.
I have quite a refined writing workflow and switched to working in plaintext files and Markdown. I have been using computers long enough to have plenty of files (CVs and essays, for example) that are now in redundant file formats and that I can no longer open. Microsoft Word is one of the most bloated, slow word processors in the world (more on this in a moment) and I hate using it.
I switched to plaintext some time back, but the rise of smartphones and tablets made that process much more valuable. In the absence, originally, of anything like Word or Pages on the iPhone and iPad, an ecosystem of plaintext editors sprang up, because all those devices could open plaintext files and plaintext files will always be something that can be opened, so they are future-proof and Dropbox made the whole storage and syncing issue much easier. Start a doc on your iPad, then open the same doc from Dropox on your laptop and carry on where you left off. Have a great idea on the go? Add it to your document on your iPhone.
I use either Byword, IAWriter or, more recently, Editorial. The advantage of the first two is that they have Mac desktop counterparts, but the big advantage of working in plaintext is that any text editor – even the venerable TextEdit – can be your word processor. They are fast, they are cross-compatible and they force you to concentrate on the content, not the formatting, which is the other key reason for working this way.
You can get really fancy with this process and use Pandoc with Markdown to write, format and export beautifully formatted academic papers if you want. If you are new to this, I can recommend the eBook on Markdown by David Sparks and Eddie Smith and also check out Brett Terpstra’s app, Marked (and almost everything else Brett offers – the guy is a godsend). He also keeps a
But I digress…
For reasons that I cannot remember, other than the fact that we knew we might need to track changes, we ended up using Microsoft Word as the format of choice. I already switched away from Word halfway through writing my PhD because Word starts to choke on long documents. Once you get beyond about 10,000 words, it starts to feel like remotely using a computer from the 1980s over a 2400 bit per second dial-up link. You type and the words appear on the screen half a second later. But it has track changes, which should be useful for collaborative writing.
In the end, I chose to be The Keeper of the Master Document. If you are all contributing to the same documents, somebody has to pull them all together and it really should be one person. We had one moment when we made a whole load of corrections to an outdated document, which meant a lot of merging and change tracking work for no good reason. I broke the manuscript up into chapter documents, so that we could send early chapters off to JoAnn to edit while we worked on getting other chapters finished. In the end, I put each chapter in its own folder and each folder had a folder within it for the appropriate images. Everything was shared on Dropbox. There was also a folder of old versions of the docs so that we could go back if we made a mistake.
This all worked okay, but was actually quite a pain to manage. Google Docs offers collaboration tools, of course, but it’s not the best word processor in the world. The Markdown and plaintext movement has led to an explosion of tools for doing this kind of thing, all at different stages of development. Editorially was lovely, but about to go offline. Draft is really pretty amazing and allows you to sync between Google Docs and Dropbox (so you’re not always beholden to typing in your browser like some other web apps) and, now, track changes:
I think I would consider using Scrivener in future, not as the word processor itself, but because it allows you to work on all the parts separately (and in Markdown plain text format) but keep them bundled together and export them usefully. I even know of people who use Github for writing because of the wonderful version control (Penflip is the result of someone building an online app around this idea. I told you a whole ecosystem had opened up).
So, after that odyssey, what are the lessons I learned from the process?
- File carefully in the first place. You are building a complex beast, piece by piece and every bit of sloppy filing will come back to bite you later.
- Meta-tag your photos (in Lightroom, Aperture, etc.) because you won’t remember in 12 months or more what or where they are.
- Source the high resolution images as you write, not afterwards, just like citations.
- PDFs can be tricky too. We had cropped and exported elements from PDFs made for projects, knowing that the vector art would be better resolution. But these caused problems in pre-press and copy editing due to the lack of fonts or Postscript weirdness. Make sure everything is outlined and flattened.
- When documenting commercial projects, shoot some photos in which participants’ faces and sensitive client material are not visible. Then you can use them later without problem, either when writing about them or presenting at conferences.
- Not all parts of a project end up in the public domain, like a website, so, even better, get your client to sign off on some publicity images (for writing about or presenting the project) at the end.
- Do not use Word. Ever. Delete it and use one of the many better tools out there.
- Put some budget and time aside for meeting face-to-face. The good thing about working remotely is that you really make use of the precious face-to-face time and don’t waste it on meetings.
- Writing a book is a long haul. Making an actual book that you hold in your hands (or even on your iPad) is an even longer haul.
Andrew Polaine March 19, 2014