Developing Drafts

As explained in Audience and Authoring, I’m quite clear on the goals for how I want to write. What I need is a simple, relatively foolproof, framework-agnostic way of shunting ideas around and drafting paragraphs without entanglements to hierarchical directory structures, schemas, types, and other computational machinery (Git and CMS config, JavaScript and CSS build tools, etc, etc, run out into the street screaming with palms pressed to my face, set fire to it all).

At some point, this minimalist idealism has to hit the actual material universe. Rubber needs to squeal on tractive surfaces. Cogs and gears need to lock into place. This part of the redesign is all about navigating friction and getting robust systems in place.

To get into the problem space a bit deeper, I first want to look at the current process of getting things onto the site:

  1. Collect whatever in a mix of semi-structured text and image files in the drafts folder
  2. Decide to publish a draft
  3. Edit and merge draft into single Markdown file
  4. Copy final draft into site content directory (or create new file and paste the text manually)
  5. Add metadata and tweaks for publication
  6. Test in browser
  7. Repeat 5) and 6) until happy
  8. Bombs away
  9. Spot egregious mistake or typo as soon as the writing has a public URL and bash out a hotfix edit, hopefully before too many people see it

Notes and bliki-style pages are little more than copy/paste and a couple of metadata edits, so can be converted and put out on the site in minutes or seconds. This contrasts with longer form content where it can take anywhere from 15 minutes to 3–4 hours to get a complex interactive essay or visual talk transcript edited and tidied up for publishing.

Having a separate, non-internet-connected drafts folder has helped make my writing process more bearable and creative. At first glance, it doesn’t seem like there’s much more I can do to simplify and speed up this process. It feels like the main impediments are more to do with the oscillating coherence and decoherence of the way I write and think than anything directly relating to tools or software.

Looking critically at the list above, the most awkward things that stand out are steps 2 and 7 and the biggest opportunities for automation/consolidation are in steps 3–5.

With 2, how do I decide to publish a draft? Is it when I feel a piece of ‘content’ is ‘ready’? Or is it when I commit to working on a new piece of writing and design for the site? If something is in the drafts folder, is it always implied that it’s headed for publication on the site?

With 7, this interative feedback cycle feels like it needs to be happening much earlier in the process. The tweaking and testing loop should be complimentary to the writing process and able to happen at any time, from the creation of the original draft onward.

In terms of optimising the preparation of drafts for publication in steps 3–5, all this seems relatively straightforward to automate if there was more clarity around the information architecture and sitemap.

Examining these problems leads to thinking about whether there is a single change or decision that could address all these aspects at once.

Here’s what I want to try:

  • Add a tiny bit more structure to the drafts folder by requiring each draft to be a named folder
  • Spin up a local web server that can treat each new draft as a standalone website
  • Create an automated task that converts unstructured drafts into usable chunks of organised content for the website

This list turns out to be a bit of an ad-hoc mixture of steps in a process (tasks to perform) and design and software changes that need to be made.

I was previously not enforcing any structure at all on drafts—this was a mixture of directories, individual documents and collections of multiple documents. Probably not as messy as many people’s desktops or browser tabs, but definitely not clean or streamlined in any way.

Still no metadata or defined schemas or file structures necessary—the only requirement is that each draft has a URL-safe named folder. I’m happy with this. It keeps things contained and separated enough and means I can working on documents about anything using my favourite typefaces and writing apps without feeling I need to do anything special to publish on the site. Once I make the decision to queue a draft for publication editing, I can run the script and copy it straight into the site structure. The useful thing about this process is that the decision to publish can happen any time—straight away after writing one or two paragraphs I want to keep or as a more defined step in an essay workflow after weeks of messy and chaotic research and gathering.

I’ve probably thought this through well enough to go ahead and make the workflow happen. The problem now is the dependency on resolving the information architecture. I need to know how to copy and convert drafts into the site structure before I can set up an automated task. So I need to consider burning the notebooks first.