Dr Robert N. Winter

From time to time, I contemplate how I publish. This is in part because I am something of a platform junkie, but also because I like 'the elegance of a refined workflow'. A euphemism which should be read as: corporate IT is bloating applications and driving development in the direction of a subscription-based, privacy nightmare.

This has seen me ponder things such as:

- Why are MS Word documents so large?

- Why do I spend so much time formatting documents in the draft phase? Why do I keep task switching when I should be writing?

- Why do some applications use proprietary formats?

- Why does adding a reference to a large document take so long?

Many of these questions have been answered by a look at the tools I use, and brings me to the focus of today's musing: the technology and process of how I write. For regular readers of this blog, you may think I've written about this [before](/how-i-write-technology/). But that article was focused on physical elements of the writing process. A good desk and chair, decent monitor, and quality keyboard.

These physical elements matter. I recall an interview with the late, great Peter Ustinov in which he talked about character acting. The interviewer asked why he manifested mannerisms, such as stooping or holding his arm in a particular way, when he was only mimicking a voice. His answer was that to get the vocal reproduction just right, he needed to physically reshape his mouth. Thus other physical elements — such as how he stood — impacted this process.

While on a less impressive scale, my writing process is similar. Having a mechanical keyboard on which to type, comfortable sitting position, large screen and app windows in their preferred place, all affects my writing process. This relentless determination to refine how I write has seen me recently look at changing my workflow.

## From Word to Writer

My first step was to migrate from MS Word to Libre Writer. This immediately yielded results as the application felt that bit less bloated. For those of a [tin foil hat](https://en.wikipedia.org/wiki/Tin_foil_hat) disposition there is also the knowledge that Microsoft can't potentially scoop up every word you type and check them against a central database. Returning from that excursion, Libre Writer also sports an interface which, and you may scoff at this, made the words on the screen seem clearer and ideas flow more easily. The migration from [EndNote](https://endnote.com/product-details) to [Zotero](https://www.zotero.org/) also helped as EndNote's proprietary software and subscription model was locking my future production into their ecosystem. I had tried Mendeley, but the way the app 'vanishes' every time I add a reference was distracting. Particularly if I need to double check a reference, as I am locked out of the Mendeley interface until I close the add reference dialogue.

Yet for all the leanness, as word count and references reach book length proportions, even Libre Writer starts to lag. Most noticeably, when I add references. Waiting 30 seconds or more while the app shuffles everything around to insert a new reference is not conducive to a distraction free environment. I tried splitting my larger pieces into smaller sections, but this brought it's own problems — such as reassembling the sections in the final document. Perhaps ironically, simply copying and pasting each section into a single large document introduced a mass of formatting issues as font changes proliferated throughout the document. Something that created yet another problem for which to solve.

Assuming I couldn't be the first person to notice these issues, I went on the hunt for a distraction free and **scaleable** writing application.

This latter category, scaleable, was key as there are no shortage of 'distraction free' apps out there. The problem with most is they strip back the writing environment so vigorously, they have the reverse effect. In that they inhibit the writing process because there is little or no integration with a reference manager like Zotero or total absence of a way to export multi-section publications in a single final draft document.

I initially tried [Scrivener](https://www.literatureandlatte.com/scrivener/overview), a beautifully crafted application. It's drag and drop interface and export process means you can write your piece one section at a time. This is a highly valuable method for both fiction and non-fiction writing as you can focus on a scene or argument and then the app compiles everything into a single narrative flow on export. It also offers planning tools — such as the corkboard and outliner — so you can 'step back' from your work and view it at the macro level. Scrivener also benefits, unlike its competitor Ulysses, from not using a subscription model. Buy once, use forever — until of course a newer version comes out and you want the additional features.

Yet for all this, there was still the lock in problem. Perhaps more so than MS Word because Scrivener does not store a manuscript as a 'single document' but as a project file with character sketches, locations, research snippets etc. all contained within. While helpful, this is problematic if you ever stop using the app or the dev firm calls it a day on the product. I think the wonderful devs at Scrivener would rightly point out that all content is saved in the project file and that it can be extracted and then read by any other applications. While this is true, the naming conventions are not human friendly. Meaning you need to export as a .docx or other file and then break it back out into sections or spend weeks combing through the myriad sub-directors of the Scrivener project file to fish out your work. Either way, you are back to square one in terms of a future proof solution to your writing workflow.

There was also the problem that Scrivener doesn't have a Linux version. Meaning it won't work natively on my OS of preference. If there was, the quality of the solution is just about good enough to tempt me to run the risk of the solution being future proof. But alas — so the quest continued.

## Markdown

The solution to my problem has come in the form of markdown. A format which is readable by every text editor known to humanity and which militates against wasting time trying to refine the look and feel of your draft because you can't manage paragraph or heading styles (beyond H1, H2 etc.). A procedure which, in any event, should be left to the publication process. After all, whether the first line indent on a paragraph should be 1 cm or 1.27 cm is something about which the typesetter likely knows best. The writer should focus on content and form.

Yet with such a ubiquitous format comes the problem of project management. In that at some point all these scenes, arguments, notes and references need to be packaged for publication. Something which usually requires a MS Word file as that is the application most editors still seem to use to tart up your magnum opus before the work is foist upon an unsuspecting public.

Of the markdown editors I've been exploring, [Zettlr](https://www.zettlr.com/) offers more of what I need in a 'work by default, customize everything' workflow. At the core of Zettlr's philosophy are the principles:

* … it does not mess with your files. You see everything, and it makes use of zero custom elements so that each Markdown file composed with Zettlr works in every other editor, and with every parser.

* … it attempts at automating everything without being opaque. We all like it if a software seems to read our mind, but if it does things without you being able to stop it, this is frustrating. Zettlr doesn't do that.

* … it enables you to do as you like. No workflow prescribed, it's only a workbench for you.

This means that straight after install I can write, cite and export to Word or PDF. But the joy of Zettlr is that if I want to customise my workflow, and being me naturally I do, there are a raft of options.

## Zettlr

There are two prime functions with which Zettlr can be the linchpin of the workflow: notes and output. That the app name Zettlr is derived from the German Zettel [note], should surface the notion that it is a powerful solution to the note taking problem.

Where Zettlr goes a step beyond traditional note taking is it leverages the Zettelkasten Method. Literally meaning 'slip box', zettelkasten was pioneered as far back as the sixteenth century by [Conrad Gessner](https://en.wikipedia.org/wiki/Conrad_Gessner) who needed a method for organising notes in a way that could be easily indexed. Fast forward a few hundred years, you can read the potted history on [Wikipedia](https://en.wikipedia.org/wiki/Zettelkasten#History), and [Niklas Luhmann](https://en.wikipedia.org/wiki/Niklas_Luhmann) (1927–1998) built up a zettelkasten of some 90,000 index cards for his research.

The principle of a Zettelkasten is simple, one creates unique identifiers which link one card to another, creating a relationship between otherwise disparate notes. I should add a note of warning here. While powerful, zettelkasten is a method **NOT** a plugin or function. In other words, if one expects the application to take care of the connections between zettel, disappointment will inevitably ensue. Instead, a zettelkasten requires planning and forethought. But it is a process which amply repays the effort.

Once your notes have been taken and you are ready for the first draft of a long form document, this is where Zettlr comes into its own. Much like Scrivener, the Zettlr app lends itself to the compiling of complex and long form works from a myriad of sections. But where Zettlr is a step up is in how files are stored. This is because each 'project' is manually created and curated by you. This means you can choose your own adventure when it comes to file and folder hierarchy and naming conventions. Should you ditch Zettlr, everything can be easily read in your file system or opened in another app. A process which gives productivity gains today and future proofing, should your application preference change tomorrow.

### Referencing

Where the Zettlr breaks new ground, and seals the deal over Scrivener for reference output, is in how it works with citations. Instead of a direct integration or plugin, as with MS Word or Libre Writer, Zettlr instead leverages a CSL JSON or Bibtex export of your references. This means that you are also freed from dependence to your reference manager of choice. Instead, you can create an export file from any reference manager and Zettlr can pickup the database. Making the referencing process truly source application agnostic and taking another step toward the utopia of avoiding platform lock-in.

Once [setup](https://docs.zettlr.com/en/academic/citations/), citing a work is a simple as '@', then start typing your reference.

### Export Formatting

When it comes time to export for publication, this is where one of the main benefits from working in markdown comes. Because there is no native formatting — above and beyond headings, italics etc. — it means I have a genuinely clean document once I export for public consumption. This differs from working in Word or Libre Writer where I invariably find direct formatting has been applied to a word here or sentence there, meaning I need to track down every instance and expunge the culprit. A **VERY** tedious process when working on a piece that is tens of thousands of words in length.

Because Zettlr leverages the powerful Pandoc and LaTeX engines, you get perfect formatting each and every time. Simply select your template and, as if by magic, a PDF, .odt or .docx file is produced to perfectly match the required output document formatting.

For those who routinely work across multiple reference styles, Zettlr also allows you to specify your reference preference at the project level. So you can alter your export style by selecting a new template. No messy reworking when moving between 'in text' and footnote / endnote style guide requirements.

## A Git in Time, Saves Nine

In 1732, [Thomas Fuller](https://en.wikipedia.org/wiki/Thomas_Fuller_(writer)) published [Gnomologia: Adagies and Proverbs](https://archive.org/details/gnomologiaadagi00conggoog/page/n11/mode/2up) which contains the first recorded instance of the phrase 'a stitch in time, may save nine'. The premise being that a little work today, saves more work tomorrow. This is especially true of the writing process. Things we pen today, may save us much research and ponderous thinking tomorrow.

To that end, I am in inveterate saver of files. But this creates its own management issue as 'document 1.odt', 'document 1 202110.odt', 'document 1 202110 (copy).odt' steadily pile up. Usually leaving me at a loss to explain what changes were made and why a copy was created — enter git.

Those with a development background will be familiar with [git](https://en.wikipedia.org/wiki/Git). For those who think [it is an insult](https://en.wikipedia.org/wiki/Git_(slang)), git is used for tracking changes in files. While mostly used by teams working on programming projects, it can also be a powerful tool for writers as it tracks all changes and allows you to have a single file, but with the ability to access a rich history of alterations. Think the track changes function in Libre Writer or MS Word, but with the ability to go back to any historic version after you've saved your changes and create a new document from that point with a different set of changes.

This opens up fabulous opportunities when it comes to edits as you can subtly, or radically, change the timbre of your work and not only have a historic copy of previous edits, but a description about each snapshot to remind your future self why you made this change. Changes that can be compared against any historic version at the document, section, paragraph, word or character level.

The end product of this markdown process is not only more granular control of the creative process, but also dramatically reduced file sizes. Perhaps not something many people care about in a world governed by exabytes rather megabytes, but one which resonates with me. That a .docx file with no content is 12 KB, yet my .md file is 0 KB, reminds me of both the mystery and magic of working in markdown — or perhaps that should be the horror of working in Word.

Under my new markdown + git workflow, a ~70,000 word manuscript, with historic edits takes up < 1 mb disk space. Compare and contrast this with my with my previous Libre Office process that had multiple .odt files chewing > 54 mb.

All in all, the switch to Zettlr has provided a more responsive writing experience, enabling an effective modular composition methodology that yields beautifully formatted manuscripts for publication. A distinct improvement to my literary process.

Goodnight and good luck.