The System of Writing

Sometimes when I take huge breaks from writing anything here, it’s just because life has gotten in the way and my lack of writing discipline equals an inability to overcome it and put in the work anyway. But sometimes it’s because I’m overhauling my entire writing workflow. That is in fact the reason I’ve been AWOL for the past couple of months. Prior to that, it was just personal failure.

I may not be the most prodigious writer, but I still love to have a system that works and that I can tune to my heart’s content. I generally do most of my writing on my iPad Pro which informs my choices in terms of editors and automation tools for publishing. My websites are static sites, compiled with Hugo static site generator. In addition, GitHub is an important part of the equation, as pushing an update to the main branch of any of my site repositories results in the web server pulling and compiling the updated repo.

Ulysses was my choice of text editor for blogging until last week. I wrote a little bit about why in a post detailing the bundle that Ulysses uses when images are inserted in the file. The ease of processing and publishing a post with the images already attached is really nice. I don’t want to choose images at publish time, I want to choose them at write time, just like most people expect to do whenever they’re writing something to be posted on the web.

The bottom line is that whatever markdown editor I use has to be able to show me the images inline and then allow for a workflow in which once I’m done writing, I don’t have to do anything additional to get the images renamed, resized if necessary, and published to the correct location on the server with the article.

While Ulysses does make creating shortcuts around this workflow very easy due to its ability to bundle images complete with image metadata, there are some things about it that bother me a little bit. One of them is the way it hides certain types of markdown such as URL links. If that’s how they want it, that’s fine, but the UI presentation of this feature leaves a little to be desired. Often I cannot tell if I have a space before or after the text containing the link due to the weird extra padding they add in the linked text.

On top of that, I have only ever used Ulysses for blog posts. For other types of writing, be it journaling, notes, documentation of procedures or projects, and other things that aren’t for public consumption, I use other apps such as Drafts and Day One. All three are wonderful apps in their own right, but all three are also subscription apps and I’d really like to consolidate a bit if possible. Given that Ulysses is the app I feel the least flexibility with in terms of what I like to use it for, and given that its UI paradigm bothers me a little bit, I decided to finally see if I could create a workflow for blogging using Drafts that would make me happy.

Drafts has always been a powerhouse of an editor, but a few recent changes have really made it possible for me to consider it as a full-fledged writing app.1 The first is Workspaces, the second is Themes, and the third is some mental shift on my part.


Workspaces can essentially be thought of as a formalization of tags. In terms of presenting Drafts to you from the Drafts list, a Workspace is like a folder. However, Workspaces can also be customized with action sets and themes to make the writing environment perfect for that particular Workspace.

When I’m writing blog posts for my personal website, for example, I like to use the Night Owl theme combined with a variation of Tim Nahumck’s Draftsdown syntax, which is itself a variation of the built-in MultiMarkdown syntax. I also have an action set called Write, which has various actions for inserting Markdown syntax, choosing images and setting them up for previewing, starting a new post from a template, publishing a blog post, and more.

Workspaces basically function around tags, but they can be much more granular than that. You can create a Workspace for all Drafts that contain specific text or that fall in a certain date range.

In addition to filtering what Drafts to show through tags, date ranges, and text content, Workspaces also have settings for themes, list order for the different boxes (inbox, flagged, archive, all), and much more. I like to have some Workspaces show everything in the inbox in ascending order by name, whereas for my Workspaces related to writing, I like to have the inbox sorted by date modified in descending order.


It may seem odd, but one of the things that kept me from using Drafts for writing projects for so long was appearance. I like to be able to customize my writing environment quite a bit unless the app I’m using is magically perfect already, which they never are.

While Drafts has never been what I’d call ugly, I also had some issues with its basic appearance and never quite found something that made me want to make it my app for spending a lot of time writing in. Instead, I used it for documenting work-related procedures and pieces of information I’d need later, more like a reference app.

With the advent of themes, Drafts can really take on whatever appearance you like, and for me this does make a difference in its appeal to me as a long-form writing app. It’s also really helpful for context switching, because when combined with Workspaces, it means my work life can take on a whole different look and feel from my personal writing projects and vice versa. I have actions for switching to my various Workspaces which also apply a unique theme for that Workspace, along with an action group and action bar group specific to the task at hand as well.

Mental Shift

I mentioned that part of my switch to Drafts for creative writing projects like this site is also due to a mental shift on my part. It’s true.

I have used Drafts for years, and primarily in recent times it’s been my personal work reference and documentation tool. I may use a PC laptop at work, but I always have my iPhone with me, and I document a lot of work specific notes and technical items to remember in Drafts. Often I write them up on my iPad and reference them on the phone.

But recently I started re-reading Tim Nahumck’s excellent MacStories review of Drafts 22 and thinking really hard about how I could incorporate Drafts into my life even more. Apparently something clicked, because I went nuts for about two days and started reorganizing Workspaces and actions and various drafts, and really banging out a system that works for me.

First, for all my really important Workspaces, I’m utilizing the Wiki link capability that Greg added in Drafts 20. Using this, I create a draft in each Workspace that is my “homepage” for that space. I call it “insert-topic-here Wiki”. For example, for my programming Workspace, I have a draft called Programming Wiki. For my job, I have a Monolith 3000 Wiki.2 Each of these has links to other drafts in the same Workspace that are for specific things: tasks lists, project details, server setup and configuration details.

Second, I finally grokked actions on a personal level. I know what actions are and what they can do, and I’ve used a lot of actions over the years. Now, though, I am creating cohesive sets of actions that make sense for a specific job, and I’m getting rid of actions I don’t need and adding ones I do. I’ve scripted several custom actions myself for things like adding to-dos to my task list drafts in the correct place depending on what kind of task I’m adding, and for archiving completed tasks into a task archive draft. And since the add task action also calls the archive task action, every time I add a new task, completed tasks get archived automatically.

Editing actions in Drafts can be a bit of a pain, not because Greg hasn’t included a very nice editor (he has), but because in order to test your code, you have to tap or click several times to back out of it and save the changes to get back to your actions list so you can run the action. If you get an error, then you have to reverse the process to get back INTO the script inside the action to fix it and try again. It’s time consuming.

Fortunately, there’s a secret that I never knew until this past week when I was doing my Drafts deep dive. You can just create a normal draft, type all your javascript there, and execute it in place without ever having to bounce around between the action group and action edit script mode. All you need is the Eval Draft action or the JS Scripting action collection or equivalent (you can even just write your own action that performs an eval on your draft). It’s a thing of beauty. This capability really speeds up the action authoring process. I used it myself tonight while updating my Add Task action’s input prompt form with a toggle switch setting for either adding the new task to the top of the task list (toggle is ON), or adding it to the bottom of the list (toggle is OFF).

Drafts is kind of insanely powerful, frankly. And while my blogging workflow still requires that I use Shortcuts, it also relies on a couple Drafts actions. For example, I have an action I wrote called Insert Images that lets me add customized markdown image links to images from my photos library at the current cursor location, and also copies the images to two iCloud folders – one to allow Drafts to preview the image while I’m writing, and the other for Shortcuts so my publishing shortcut is able to add them to my site repo along with the markdown file for the post itself.

I’m going to break some of this down in the future and go into much deeper detail about each of these aspects of Drafts and my publishing workflow, because there’s a lot to unpack with incorporating Drafts as the center of a writing system that also relies on the power and reach of Shortcuts. Before I start on that, though, I need to wrap up my series on SSH.

  1. As well as for other things, but I’ll cover those another time. ↩︎

  2. Not my employer’s actual name. ↩︎