|||

writing workflow

I write a lot and for many different purposes: research reports and presentations, blog posts, grant applications, academic articles, responses to students, reflective writing, texts for performance …

This writing involves, to a greater or lesser extent, three simultaneous processes leading up to publication: collecting, processing and writing. That these processes occur simultaneously (with variations in focus depending on the project, and what stage of it I am at) is critical. In other words, writing for me is never: collect then process then write. I attempt to start writing immediately as part of the process of understanding what it is that I am attempting to articulate.

This blog post is an effort to share the different tools I use in these (mostly software-oriented) processes. It’s not my usual kind of post, but perhaps it is of interest to those of you who spend time writing.

Collect

These processes have changed enormously since my time as an undergraduate and masters student in the late 1980s/early 1990s. In those days we dealt with two ways of getting a feel for what was going on in the world of our discipline: periodicals (journal articles) and books. Later we’d use CD-ROMs to get more up to date information.

The following is a list of how I currently collect information that feeds into my writing:

  • RSS feeds — whatisrss.com
  • Google alerts — google.com/alerts
  • Physical books and e-books (I use a combination of iBooks and Kindle books, both read on the iPad)
  • Journal subscriptions
  • Twitter and app.net — twitter.com, app.net/
  • References from current and past reading
  • List-servs
  • Videos (almost all online through YouTube, Vimeo or sites like Culturebot and Open Culture
  • Performances
  • Websites

Process

I’ve found developing strategies for handling or processing multiple information streams the most difficult to make as efficient as possible. Indeed, I’m still not there, and these processes involve a certain amount of redundancy (or duplication) that is not ideal.

  1. Convert to PDF where possible:

    • Download original PDFs
    • Scan physical chapters or articles
    • Save direct from website (I do this with either Evernote, CleanPrint extension for Chrome or simply using the Print to PDF function in OSX
  2. OCR PDFs in Evernote, Devonthink or Scansnap to ensure all PDFs are searchable

  3. Add to Papers — this is citation software used to add references to writing, and to automatically build reference lists or bibliographies.

  4. Annotate PDFs in iAnnotate for iPad (I do nearly all of my reading on an iPad)

  5. Add any notes to DEVONthink as small (paragraph-sized) text files which are grouped into a folder that equates to the reference or paper they came from

  6. Use Drafts to process small notes and ideas from iOS devices direct to nvALT

  7. Pocket — a read-it-later service for offline reading on iOS devices and in browsers

Points 3, 4 and 5 are the major redundancies in this system. For example, I could add notes to references in Papers, and read PDFs stored in Papers on the iPad. But, although iAnnotate has rather clunky sync services (across Dropbox) I really like its annotation tools and how these notes get synced with the PDFs.

Generally speaking, I also tend to avoid database-based systems where possible1 (what happens if that supplier goes out of business?) but DEVONthink has strong artificial intelligence features for linking diverse ideas that make it worth my while.

These applications do, however, cost money (DEVONthink is pricey), and with students I tend to suggest using Evernote as a way of processing information, combined with their University’s citation software (Roehampton University uses Refworks which is painful to use compared with Papers). Any academic or aspiring academic who is not familiar with one form of citation software is making a very big mistake.

Write

The key here is writing in text files using Markdown. This is for three reasons:

  1. Text files ensure backward and forward compatibility. There will never be a time when computers can’t read a text file, whereas even documents I wrote in the 1990s are no longer accessible to my current computers;

  2. I can get stuck into the process of writing without getting lost in the formatting power of applications like MS word;

  3. Markdown is not platform dependent. I can write on a laptop, a tablet or phone, and then these can all sync automatically. For example, I can quickly add an idea to a book chapter I am writing using my phone which will then be available when I go back to editing the book on my computer.

Markdown is, quite simply, brilliant to write in. It is simple to learn, flexible, and doesn’t require any special software (just a text editor). There are lots of resources online for learning Markdown but David Sparks and Eddie Smith’s The MacSparky Markdown Field Guide is very fine indeed.

The software (text editor) I most often use for writing is Byword (available across platforms with automatic syncing via Dropbox or iCloud). It looks good, is distraction free, and is all about the writing. Occasionally I use Ommwriter for a bit of variety, and for longer documents I might use a combination of Multimarkdown and Marked. Most recently, I’ve started to incorporate Scrivener for multi-chapter projects. I still do the writing in Byword (Scrivener enables me to sync text files automatically), but Scrivener is very useful for, for example, re-ordering chapters. My understanding of Scrivener though is nascent (at best), and I’m still not convinced it is that useful for how I go about developing and articulating ideas.

Publish

My writing tends to get published (or shared?) either as HTML for the web or as Word documents. It’s simply unavoidable using MS word in academia. I can’t ignore what my colleagues are most familiar with, and the track-changes function is very useful for working collaboratively (although I’d prefer we used Google Docs for this where possible) or for annotating student work.

Markdown was created as an alternative syntax to HTML and I can generate HTML code directly from, for example, Byword. Getting Markdown into MS Word (and having the integrity of headings, lists and paragraphs maintained) is a bit more tricky. I use Pandoc for this. It is pretty much faultless for creating Word .docx files but it does mean using the Terminal in OSX.

For creating reference lists, I tend to do this at the very last minute. If I am sending off an article as a Word document I build the reference list (using Papers) after I have converted from Markdown to Word.

That’s it — phew. Oh, I should also mention Textexpander. It is a priceless time-saver and probably the software that I use most often without remembering that I am even using it.


  1. This is why I stopped using Evernote as a catch-all for ideas and sources.↩︎

Up next thinking is dangerous michael vs ken On Thursday 9 May 2013, the UK’s Education Secretary Michael Gove gave an impassioned speech about his concerns about — and plans for — the UK’s
Latest posts hands that don’t want anything singing and dancing losing oneself given a price on remembering everything Godin on ideas three chairs growth felt in christ Freelance Dance Artists’ Working Ecology he danced listening and pain Somatics unlimited body politics vernacular activities one sentence email tips scrutiny ripeness Dance after lockdown - living with paradox mini essay Esther May Campbell a community of practice a nest for hope Colin, Simon and I archive power of a lifetime now: 4 January 2023 Editorial: Making choreography, making community Fading out the human presence: A conversation between Barbara Stimoli, Titta Raccagni and Simon Ellis brittle with relics the land in you Attention