Notes on Workflow and Tools in the Construction of Tactile Paths

This document offers a look at the workflow and digital tools I used to produce the native digital PhD dissertation in artistic research entitled “Tactile Paths: on and through Notation for Improvisers” (henceforth TP). It is an appendix to “Lessons from the Sandbox: Linking Readership, Representation, and Reflection in Tactile Paths”, forthcoming in a volume on digital dissertations edited by Virginia Kuhn and Kathie Gossett.

In the above video, I discuss some ideas from “Lessons from the Sandbox” and some ideas from this text.

At the end of the text I have provided suggestions for further reading. These may be of use for readers interested in building their own web-based thesis in the arts.

Problems with Word

TP is a native website. However, the dissertation writing process began – as it does for many scholars in the humanities – in Word documents.1 This was a default; I did not previously have the occasion to research alternatives. Since my supervisers preferred to use this platform for commenting and editing, I had no reason to question it.

Fairly early on, however, I became frustrated with Word. For one, documents longer than 15-20 pages often ran unstably and caused the program to freeze. Documents with extensive embedded comments or high resolution images were particularly problematic.

Furthermore, content and styling (page layout, typography, line spacing, etc.) are bound together in Word, which created a source of distraction from the writing itself. How many other writers kill time by playing with the font size of subheadings, or endlessly deliberating if a paragraph should begin at the end of a page or the beginning of the next? More than a few, I would guess.

Perhaps the most frustrating aspect of Word was version control, or managing various drafts with comments and edits from my supervisors. A typical chapter would undergo multiple rounds of review, sometimes saved as different versions, sometimes with different filenames. One supervisor might insert comments as comments, another would write in a different color directly in the text body, another might simply make comments in an email or personal conversation. Suffice it to say that there are better ways to edit collaboratively. I wish I had known about them earlier.

The straw that broke the camel’s back and forced me to find a better writing platform was when my designer and I settled on WordPress (WP) as a web platform.2 Copying formatted text from a Word document and pasting it into the WP editor was an unpredictable process. Some aspects of formatting (e.g. spacing) would carry over, but others (e.g. italics) would not. The only reliable way to proof WP formatting after transfer was by sifting through the content in WP’s HTML viewer, which was time consuming. So I ended up pasting Word content first into a text editor, then copying it again, pasting into the WP editor and formatting manually. Not very efficient.

Markdown for Master Docs and Pandoc for Conversion

Enter Markdown, a simple markup syntax in plaintext. Markdown has numerous advantages for academic writing:

  • Files are light and look the same on any any text editor.
  • Formatting structure is crystal clear and future-proof (as long as text editors exist!).
  • One deals with styling independently of the content.
  • Many other points elaborated in blogs and tutorials such as Nicolas Cifuentes-Goodbody’s helpful YouTube tutorials.

In tandem with Markdown I used Pandoc, a command-line tool that can export Markdown to HTML, Word, styled PDFs, LaTeX, and convert between all these formats. With Pandoc I could export a master document Markdown to Word to share with my supervisors, and to HTML for the website. It also provided the possibility to convert documents already written in Word to Markdown for consistency among the master documents. Working with the command line permitted me to integrate simple scripts for automating the preparation of footnote shortcodes in WP and a few other idiosyncracies. In short, the combination of Markdown and Pandoc streamlined my workflow considerably.

LaTeX for Typesetting and Zotero for Bibliography Management

Although my advisors at Leiden University were consistently supportive of my decision to publish TP as a website, they also required me to submit a hard copy.3 Having become disenchanted with Word for reasons mentioned above, I decided to produce the PDF with LaTeX. LaTeX is a cost-free and open source typesetting language common in the hard sciences and some social sciences, but less common in the humanities. For users unfamiliar with computer programming, the learning curve is steep, but the benefits in comparison with Word are many:

  • Output PDFs are light (my final 155-page document weighs 1.1.MB).
  • Layout is rule-based rather than manual (hence more professional-looking and consistent).
  • The table of contents, bibliography, and index are generated and formatted automatically.
  • A huge collection of customizable templates is available online.
  • A huge and engaged user community is also available for support.

In particular, I used the tufte-latex class, developed after renowned design theorist Edward Tufte’s books. This class contains the characteristic sidenotes and graphics settings used by Tufte in his own award-winning books. tufte-latex looks and works beautifully out of the box, so little customization was necessary.

For bibliography management, I used the Zotero standalone app and web browser plugin. Zotero collects and sorts references at the click of a button. It can export bibliographies in all common styles (e.g. APA, Chicago, MLA, etc.). I found this tool to be a lifesaver for exporting bibliographies into multiple end formats – Word, HTML, and Bibtex (for use with LaTeX).

Bumps and Possible Solutions

Learning by doing – and juggling multiple formats simultaneously – had its downsides. In the mad dash to submit my dissertation, the as yet unsettled integration of the above tools nearly fell apart. Last minute edits in Word by my supervisors got confused between the master Markdown document, LaTeX, and HTML. Bibliographic omissions and inconsistencies related to my use of manual citation (where it could have been automated with BibTex and Pandoc) spread like wildfire. Single syntactical mistakes in LaTeX resulted in chapters going missing from the table of contents. And so on.

Since then, I have had the opportunity to fine-tune this workflow for other publications. If I had the opportunity to do it again, the ideal workflow for TP might look something like this:

  1. Manage the master bibliography in Zotero.
  2. Write master documents in Markdown (1 file per chapter).
  3. Automate citation in Markdown and Bibtex.
  4. Edit and manage version control in GitHub, an free online tool used widely by programmers.
  5. Convert Markdown to HTML and LaTeX with Pandoc.
  6. Typeset with LaTeX.
  7. Web design with…

This last point remains an open question: was WP really the best format for TP? As I detail in “Lessons from the Sandbox”, it was a big improvement over the Research Catalogue, the publishing platform I initially explored. Since December 2016, I have not had to update any plugins or implement any security fixes, and the site remains fully functional. Search engine visibility has been excellent. Everything looks the same as when it was published. But that does not mean maintenance will be unnecessary in the future. Another problem is not being able to view the website offline, which occasionally is necessary when presenting in university classrooms where WiFi is not available to unregistered guests.

Static Website Generators

In retrospect, building TP with a static website generator such as Jeckyll or Hugo may have been the best option. Authors create content directly in Markdown with TOML headers (simple metadata written at the beginning of a Markdown file). Layouts are defined by separate HTML and CSS files. Content and formatting files, along with media files, live in a standardized file tree on one’s personal computer. The public website files generated by the program then can be uploaded to GitHub (free of cost) or directly to a private host. Authors can edit content in their text editor and preview directly in a web browser, even offline. This makes a separate interface such as WP’s completely unnecessary. The workflow is fast and simple, requiring no conversion to HTML or manual formatting. Since output is static, as opposed to WP, security problems or plugin obsolescence is a non-issue.

I recently rebuilt my personal website with Hugo. At the time of writing, I would recommend to any PhD student beginning a native digital dissertation to consider using this platform, which has a rapidly growing user community, excellent documentation, and a number of themes appropriate for academic writing.

Additional Resources

Adams, Megan, and Kristine Blair. 2016. “Digital Dissertations: A Research Story.” Kairos: Rhetoric, Technology, and Pedagogy, 21 July.

Butterick, Matthew. 2013. “Butterick’s Practical Typography.”

Cobussen, Marcel. 2002. “Deconstruction in Music.” PhD diss., Rotterdam: Erasmus University.

Kuhn, Virginia. 2013. “Embrace and Ambivalence | AAUP.” American Association of University Professors, February.

“Research Catalogue - an International Database for Artistic Research.”

“Vega Academic Publishing System – Homepage.”

  1. To be specific, I used the open source office suite LibreOffice for working in Word rather than proprietary software. ^
  2. I discuss the pros and cons of WP in greater depth in “Lessons from the Sandbox”. ^
  3. For some writers of native digital dissertations, this requirement is unacceptable. But one must pick one’s battles, and ultimately TP was not difficult to prepare as a PDF for administrative purposes. ^