What matters isn’t your writing software, it’s your file structures (sorry!)

Thanks to Anuja Cabraal who asked this question! It’s about 2,500 words of answer, so this is absolutely a Definitive Guide. A few of the technical details here I also discuss in my earlier blog, ‘Three secrets in MSWord that will supercharge your productivity‘, but this is a lot more comprehensive!

People often ask me about my writing software, and it’s an ever-popular question for new and long-term researchers. When we spend so much time writing and editing, it’s essential that we use tools that support us to be effective. What’s more, so many programs now make jobs quick and easy that used to take hours of focussed labour: from finding secondary literature, accessing archives, formatting references, finding themes in NVivo, making graphs, editing images, running complex equations, formatting documents, finding spelling and grammar issues… surely there’s a software that basically writes the thesis for you? Sadly, not yet!

That being said, actually it’s never been easier to get the ideas in your head out into text. I write everywhere: notes app on my phone; scraps of paper; Paper on my iPad, Word on my laptop, Google docs if it’s collaborative; some things start as blog posts, tweets, emails or telephone conversations. I don’t use the Word and Google docs voice-to-text function, but if I preferred to talk rather than type, I could easily do that. Almost all of these formats are easily moved between platforms, a simple ‘export’, or copy-paste, and suddenly it’s all appeared in your thesis! So it doesn’t really matter what software you use to get the writing down.

Controversially, I would argue that instead: The best writing software isn’t about the writing, it’s about saving all of these pieces somewhere and then supporting the structural editing stage. So basically, this is a massive post about filing systems and headings. Your software may be one product, or it might be few different digital bits bolted together. The system I set out here assumes you are building your setup from scratch—but you can also extract the principles and use it to source a software package that does some or all of this for you… or to tweak it to build system that works in whatever way you like to work. 

[At this point, someone will say ‘isn’t this basically Scrivener?’ and yes, Scrivener is designed on these principles, BUT it does so in ways that may or may not work for you. Personally I’ve tried Scrivener three different times, well spaced apart, for different projects, and I really can’t love it. It just doesn’t work for me. Other people adore it though, so do make use of the free trial and see what you think.]

Saving all of the pieces somewhere 

In a major writing project like a book or a thesis, there will be fragments of drafts, first drafts, edited drafts, drafts with feedback… and if the book is being co-authored, then the complexity increases again. In my last four books, me and my co-authors contributed different sections to each chapter, so each chapter was a mess of multiple files with multiple authors writing to slightly different timelines. We then read each other’s work, and gave feedback. The section was then edited by the original author, then we put all the sections together into chapters… and then we started editing the work as a whole. Obviously we needed to use a cloud-based collaborative platform to store and share all of these files—Google Drive or Dropbox usually—but more importantly, we needed a consistent filing system that made it easy to find the bits and put them together in a meaningful order. 

First of all, make a folder called ‘Submission Regulations’ or ‘From the Publisher’ or similar. Find all the documents that are required for handing the work in. Your book contract. The massive PDF of formatting guidelines for the PhD. The PhD examinations policy, Library repository instructions, the copy editing questionnaire… Anything that’s a website or an email, but has that information, save it as a document and put it here. Your future self will thank you. [Do NOT skip this step. It’s a top tip.]

Each time you do substantial work on your manuscript, you should save the document as a new file. (For most people, that means a file for each day you work on the document.) You should keep copies of old files, as you sometimes make a change that you want to revert. Also, if something crashes and your current draft is eaten/corrupted/deleted/botched beyond repair, you can pull up the last draft and then just have to do one day’s worth of work to recover it.

BUT most days you don’t need the old drafts and it’s unhelpful to have them cluttering up your main workspace. If your filing system is a mess, you are quite likely to waste a day working on the wrong file, so put it somewhere you won’t click on it by accident! So, make a folder for past drafts. You may want to have other folders, for example a folder for each chapter that includes lots of saved articles as well as the draft, or you might not. That bit is personal preference, I’ve done different things for different projects.

Next, you  MUST decide on a helpful file naming system. One that helps you sort your files, see what’s missing, and see what is there. And that means Numbering Your Files. You have to submit chapters as seperate numbered files to the publisher, so this isn’t some idiosyncratic idea, but an industry norm. You can use punctuation like ! for front matter, and start your numbering at 0 for the Intro if you want to keep 1 for Chapter 1. 

You can include lots of information in a file name these days, so do! For co-authored work I’d include the author and then add the editor details. I also recommend using a date format that is easily sortable, and that means year-month-day.

For example:
! Front Matter
0.1 Introduction 20-06-25 KEF
0.2 Introduction 20-05-11 JAL
0.2 Introduction 20-05-11 JAL edits KEF
0.2 Introduction 20-05-30 JAL edited
1.1 Chapter 1 20-03-15 KEF

We can see that the second section of the Introduction has gone through a first draft and edit and a new draft. We can sort the list by file name to find the most recent version, and it’s easy to move the others to the draft folder in a group.

This naming convention also makes it easier to project manage a co-authored book, to see who has written their sections… and who hasn’t. Or to see which sections haven’t been edited yet. In a traditional PhD where you work on one chapter at a time, this may be less important, but a PhD with publications is likely to have multiple articles in various stages of peer review, and so a clear file naming system will help you stay on top of it. 

Having a naming system like this also helps you to glance down the file list and see if the overall structure makes sense. (This is basically a top-level Reverse Outline). If you need to reorder your chapters, it’s pretty easy to renumber your files, but do leave a note about the old numbering in the file name or document, so you can find the old drafts! (e.g. 1 Chapter 1 used to be chapter 7 20-04-12.docx) (See more about why this is a good idea below.)

Okay, so you have stored all of these documents in a clear and structured way. Now it’s time to decide on a setup that will help you to stitch all these bits together and make it a coherent whole. 

Supporting the structural editing stage

There are no right answers here. Some people like to shuffle their sections around on the screen (as in Scrivener or the Navigation Pane in Word for PCs only), or print them out and move them around on the floor. Some people like to put them into one long linear document and cut and paste sections (this is me).

Whatever you do, it’s essential to have 3 things: 

  1. clear headings
  2. a way to work out where the text used to be
  3. a way to move between the sentence details and the big picture. 

1. Clear headings

Make the headings a distinct format—preferably using a Heading style. Most word processing software has official heading styles, using them helps you create a table of contents, to use the Navigation Pane, and to be able to eyeball what section you are on and how it relates to other sections. 

Keep up the numbering! For early drafts, you can go as granular in numbering your headings as you want to. And make the headings super descriptive. Don’t just say ‘Methods’: describe what is actually in the section. Use more than one sentence if you need to. Talk about what goes there, the themes, any instructions for your future self. This is also the place to make notes about  what your past self did, as I can assure you you will forget.

e.g. 1.1.i.a.1 Introduction WRITE THIS LAST 300 words see the Conclusion (1.7.iii.b.4) for the argument.

 Your working subheadings should help you write and edit your thesis. Before you hand the work in, make sure to reformat them into the approved style guide format! 

2. A way to work out where the text used to be

Track changes can only do so much, especially if you ever make changes on print outs, or across multiple authors. Track changes also starts to make your drafts crash if you have too many of them. So you will periodically need to move to a  new ‘clean’ document. If you edit with a pen on paper, then you can see the scribbles, but it can be hard to work out what happened two or three drafts ago. (It is possible, but I can tell you from experience it’s horrifically  time consuming!)

It can ver very helpful to include information about major revision histories in your drafts. There are lots of ways of doing this. I am a fan of using the header or footer of a document to include the file name, draft number, date, page number, the history of who has written or edited it. Then it’s on every page if you print it out and reorder it. But just having this info as a marginal comment or a line under your headings can help you to trace your way back. In the same way you might name your files with their revision history (e.g. 1 Chapter 1 used to be chapter 7 20-04-12.docx), you may choose to name chapters or sections with their revision history. 

And yes, I use this all the time. For example, for a recent book, we totally reordered the chapters right before the final submission. We’d already put in a lot of cross-references, so we needed to go through and fix every single one: ‘for more on this, see 7.2’, ‘remember we talked about this back in 1.3?’ etc etc. All of them were now wrong. If I hadn’t renamed each of the headings ‘6.2 USED TO BE 7.2 How to be more concise’ I would never have managed it. 

3. A way to move between the sentence details and the big picture. 

In the structural editing stage you need to easily jump from the big picture to the paragraph, so you can write meaningful topic sentences and other signposting. You need to check that the prose flows in a logical way to match the big picture map of your outline. You need to check that the amount of writing in a section is proportional to its importance—that side point should only be a short paragraph or even a footnote and not taking up twice as much space as the main argument! 

If you’ve used Headings styles, your software can give you a Table of Contents, Navigation sidebar, or Outline style view. In Scrivener, you can format the work as tiles. If you’ve worked on a print out, you might want to create a Reverse Outline manually. Ideally, you want to be able to view both your outline and your text simultaneously, for example having the Navigation Pane open as you work on the document. As the book gets longer and more complex, it might also mean having the structure in a seperate window, a second screen, or printed out. (Or, as I had for my most recent book project… all of the above.)

****

The closer to the end of the writing project you are, the more important these features become. I can often get away with being sloppy across a single chapter, because I can hold most of it in my head, and I’ve worked on the content recently enough to remember what I changed and why. But at the end of a project, with tens of thousands of words written over more than a year, a structure like this becomes essential. If some of those words weren’t even written or edited by me, but by one of my co-authors, then it’s even more necessary for me to understand what has happened for this piece of writing to be the way it is, and why. 

Academic writing, whether as a sole author or in a team, always involves compromises. Style choices you don’t like but which are required by the style guide. Content you don’t really want but was requested by a supervisor, examiner, reviewer or editor. Ideas that are really interesting but had to be cut for space reasons. Wording that is clunky but correct. Information you just couldn’t sourced in the time limit that had to be left out. Meaningful file names and descriptive headings help you to make better compromises. A chapter that you don’t think quite works called ‘JAL edited KEF edited PF edited IM edited SL edited LC’? Time to accept its imperfections, or talk about whether it needs to be scrapped. Either way, another round of edits is unlikely to solve the problems. 

You probably didn’t start your current writing project set up this way. I doubt your files  are this structured, or have this kind of naming convention. If you are early on in a project, you might not even feel like this will ever be necessary! That’s okay. You don’t have to have already done this.  

As soon as you start to feel overwhelmed by your mess of files, you can put this together. You can reverse engineer this neatness. 

For my last book, we each wrote in our own preferred software, and emailed each other the sections as we completed them for feedback. So we only needed this structure as we brought the book together a few months before submitting it. For now, it might be more important that you are taking good notes, getting that first draft down, and responding to feedback. Whatever stage you are at, this blog post will still be here when you are ready for it.

Thanks to my coauthors: Inger Mewburn, Shaun Lehman, Andreas Loewe, Liam Connell and Peta Freestone. I’ve learned a lot from you all about this! And apologies to anyone who didn’t really need 2,500 words on how to organise a writing project!

1 Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s