There are three ways in which any process changes:
- Forced change: “this is the way we do it now”.
- Reactive change: “our procedures don’t cover this”.
- Considered change: the deliberative consideration of alternatives that are evaluated, tested, and adopted.
The third option is almost always best. In that way, a long period of research and experimentation and one weekend of concentrated work on integrating new habits has revolutionized the way I write and develop. It’s my hope that this series might help others streamline and improve their workflow processes.
Old Perspectives
For a long time I’ve been a proponent of creating site body copy in a word processor and exporting the text into clean HTML. Using a tool like Microsoft Word has the advantage of built-in spellcheck, correct typography, and ubiquity in the office environment, and while it may continue to work in that context, I began to regard it as overpowered for my own purposes: I was spending more time wrangling code output than actually writing. I wanted something closer to the bone, but any solution I adopted had to retain the advantages of a word processor.
New Methodologies
The answer I came up with required the adoption of several new tools and workflow processes.
The first step replaced Microsoft Word with MacDown, a Markdown editor. With the correct settings – and the SmartyPants module preserving smart quotes – I had all the features I needed in a far smaller, lighter application, coupled with native HTML formatting. Plus, Macdown directly integrates Lea Verou’s Prism code syntax highlighter, which I use for code samples on this blog.
While MacDown’s HTML output was considerably cleaner than any method I had used before, code minification is still very important. Previously, I had personally HTML-optimised every article using find-and-replace in Coda before publication, but I really wanted to automate the process.
CodeKit – which I will discuss a future article – can automate the translation of Markdown files into HTML, but unfortunately it doesn’t support HTML minification. For that, I turned to a JavaScript task runner. Gulp (also the topic of a future article) has a number of minifiers available; while gulp-minify-html was a little conservative for my taste, it was a good start, to which I added a few find-and-replace rules with gulp-replace.
The result is that a Markdown document that looked like this: There are three ways in which any process is altered: 1. Forced change: &ldquot;this is the way we do it now&rdquot;. 2. Reactive change: &ldquot;our procedures don't cover this&rdquot;.
Is automatically turned into this: <p>There are three ways in which any process changes: <ol><li>Forced change: “this is the way we do it now”. <li>Reactive change: “our procedures don’t cover this”.</ol>
The original Markdown files and their processed HTML are stored on my Sync.com account, making them available from absolutely anywhere. As a result, I can spend much more of my time writing, with code formatting almost completely taken care of.
Simultaneously, I wanted to bring the same level of automation to site image creation; in the next article, I’ll show how I accomplished that.
Photograph by Thomas Hawk, used under a Creative Commons Attribution-NonCommercial 2.0 Generic license
Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.
