An Update on My Writing Workflow

One of the topics I received for Reader Request week was an update on my writing workflow. As it happens, my writing workflow is in flux right now, so I thought I’d take this opportunity to talk about where I’ve been and where I am going.

Regular readers probably know that my all-time favorite word processor was Microsoft Word 5.5 for DOS. This word processor got me through college, and was just the right mix of features and functions. Word processing tools have been adding more and more features ever since. Perhaps the most notable feature is the WYSIWYG interface. WYSIWYG is where word processors went awry, as far as I am concerned.

I have written before that a good word processing tool for writers should do 3 things well:

1. It should separate the interface from the presentation layer. The interface is the tool we use to write the words. The presentation layer can vary. The words I am writing now are for a blog post, but I might repurpose these same words in a manuscript, which is a different interface. The content should be separate from the medium in which the writing is ultimately published.

2. It should eliminate as many distractions as possible. The great thing about a typewriter is that there isn’t much to distract a writer. There’s only one font selection. There aren’t dozens of menu options and pulldowns cluttering your page.

3. A word processor should be very good at processing words. It should be fast and easy to edit text, move text around, and otherwise manipulate what you write. Moreover, a writer should be able to do this without their fingers leaving the keyboard. Mouse-clicks interrupt my writing flow.

More and more, I find my time to write limited, and I am constantly looking for ways to maximize the time that I have. Each tool that I use for writing has its own set of commands to learn. Switching from one to the other for different tasks means making a mental adjustment that slows me down.

Considering all of this, I recently began to rethink my approach to writing tool, and I came up with a set of requirements for what I am looking for.

My writing tool requirements

1. All my writing should be done with a single tool. Fiction, nonfiction, blogging, work documents, meeting notes, all of it should be done in the same tool. Then I don’t have to switch between tools throughout the day. The one exception is email.

2. All my writing should be tracked in Git. I like being able to see how my writing changes over time. I learn from that. It was one of the reasons I developed my Google Docs Writing Tracker. That said, the tracking should be automatic. I should not have to git add, git commit, and git push manually.

3. I need to be able to easily produce output in a variety of formats depending on circumstance. Stories and articles need to be in manuscript format. Technical documents have another format. The format should have no bearing on the interface in which I do the writing.

4. The single most important thing to me as a writer is the text that I am writing. I should be able to easily manipulate the text. I should be able to transform it. I should be able to analyze it interesting ways.

Writing tools I’ve used in the past

The writing tools I’ve used in the past have had some of these things, but not all of them. In Microsoft Word 5.5 for DOS, I did all of my writing in a single tool. Whether it was a political science paper, or physics notes, or a story I was writing, I used just one tool, had to learn just one set of commands. As good as Word was, it stored its data in a proprietary format. That didn’t make it easy to change from one format to another. Fortunately, back then, I was printing what I wrote and that’s it.

Scrivener does a great job of separating the content from the presentation layer. In Scrivener, you write a document, and then you compile it for the output you need. You can compile it in standard manuscript format, and then turn around, and using the same text, compile it for e-book format. This is a powerful function. But my writing in Scrivener was generally limited to fiction and nonfiction, and more recently, writing blog posts. I didn’t use it for other things. Then, too, because of the nature of Scrivener files, it is difficult to keep track of your writing in a system like Git in order to track changes over time. Not impossible, just challenging.

I used Google Docs for my fiction and nonfiction writing for more than two years. By writing some scripts, I was able to automate the tracking of my writing in Google Docs, which was a great benefit. But Google Docs doesn’t do a very good job of separating the content from the presentation layer. There were other limits that I ran into over time.

My writing tools today.

I am writing this post in Vim. That’s right, a simple Unix-based text editor in MacOS’s Terminal.

For the last week or so, I’ve been doing all of my writing in Vim, and I’ve been slowing building up (or creating) a set of tools to support this. I’ve used Vim for blog posts. I’ve used it for meeting notes at work. I’ve used it for writing technical documentation. It has come closest to meeting the requirements I’ve set out for a perfect writing environment for myself.

1. I can do everything in one tool.

2. With no menus, and a minimalist configuration for the screen, it is about as distraction free as I can get.

3. It is plain text. I use Markdown when writing, but the important thing is the plain text. It makes it easy to hook into Git. I use flashbake. This is a tool that automatically checks documents into Git at regular intervals. For me, it is every 15 minutes. Already, in the course of writing this piece, flashbake has made 2 commits to Git automatically. I can run some commands and see how the piece has evolved.

1. I’ve been using pandoc to quickly compile my writing in the format I need. Markdown is great for WordPress, because I can just paste the text into WordPress and it converts the Markdown to nice HTML formatting. For meeting notes, I’ll run a short pandoc command I wrote that creates a Word document and uploads it to a SharePoint site. I have another command I can run to produce a PDF.

This sounds like a complicated mess, but once I got the basics in place, I don’t think about them. I don’t have to think about committing my changes to Git because a script does it for me automatically behind the scenes. I don’t have to worry about the format of the document because I can produce it in whatever format I want once it is written. And I don’t have to learn a set of commands for half a dozen different writing tools. I can do it all in one place.

I’m just getting started down this road, but so far I like it. It allows me to spend my time writing, and not messing with interfaces and menus and functions. Vim is definitely a learning curve for folks who’ve never used a text editor like it, but I’ve used it in the past for other things, and I’m learning new and useful stuff about it today.