Writing is easy, right? Tell a story. The hard part is getting the story in front of people. That requires tools to get from idea to eBook (or even paper.)

I’m also a non-fiction writer. And a software developer. (And a sailor.) Tools are important. Here’s a historical view of the variety of tool chains I’ve used.

I started writing with the generic word-processing tools that came with my computers. Since getting a Macintosh in the 80’s (85? 86?) I’ve used MacWrite and ClarisWorks. They’re fine if you’re a genius.

In the late 90’s, I became interested in screenwriting and started using Final Draft. It was illuminating because it had tools above and beyond simple formatting. (And yes, I’ve got a half-dozen screenplays completed.)

In the 00’s, I started selling non-fiction books through a print-on-demand publisher, and had to ramp up my game and focus on technical publication.

Technical Writing

As a technical writer, I was a heavy user of programming tools like BBEdit. I’ve branched out a bit and now use PyCharm in addition to BBEdit.

Because of the way programming books are formatted, I learned to use the LaTeX tool chain via MacTex. This isn’t easy to work with, but the results are spectacular.

The Sphinx tools simplify working with LaTeX and HTML. This makes book publication almost easy. The steps from idea to final product are shorter and less confusing. If I was going to continue to pursue self-publishing, this would be the path of least resistance.

I’ve been using Omni Outliner for decades. It seems to be very helpful. I’ve always been a devotee of outlining tools, starting with More for the Macintosh. I find the small optimizations for expanding, contracting, dragging, focus shifts, etc., to be very helpful. Many outliners are after-thoughts clumsily agglomerated into writing tools. Omni Outliner is an Outlining tool, making it easy to capture thoughts.

For non-fiction, I start with Sphinx-based writing. My publication-ready draft must — eventually — get converted to the file format the publisher requires. Generally DOCX. Sigh. The idea, however, is the purely technical writing tools allow a lot of correctness-checking. Using Python docstring checks to validate each example is heavenly.

This works nicely for writing about programming. It doesn’t work well, however, for fiction.

Starting in Fiction

For fiction, I started with a Sphinx-based toolchain. There’s a lot of flexibility in creating notes and cross-references. The final publication format is .RTF (or .DOCX) and the general manuscript rules are easy to manage. See https://www.sfwa.org/2005/01/manuscript-format/ for details on what the final deliverable needs to look like. It’s a small step from a collection of files with simple markup to RTF (with archaic underlining for italics.)

Once upon a time, I created some tools to covert from Omni Outliner to ReStructured Text (RST). This could then make use of DocUtils to create LaTeX and .mobi for self-publishing. I was leaning heavily in this direction for fiction. It was a complex science project to get material ready for publication. And supporting the home-brewed tools gets in the way of writing. Everything involves a cool side-project and a distraction from the real job, which is to understand the characters and tell their story.

So. Forget all of that. It was exhausting.

Fiction Toolchain

Writing fiction involves (eventually) creating the text. And it also involves a lot of ancillary processing and data before arriving at that text. A lot. And messing around with the other material can lead to a bit of clutter. Files and folders all over the place.

I’ve arrived at the following suite of tools.

  • Meandering. The base Hero’s Journey is in Omni Outliner. It feels like I’m free to mess around. Using Scrivener feels too much like I should be creating deliverable drafts. (I need to get over this.)

  • Milestones and Schedules. In Numbers.

  • Miscellaneous Notes. I’ll record some ideas in IOS Notes because it’s on my phone.

  • Maps. Hexographer and Grid Cartographer. Plus my Empire and Kingdom model for simulating borders and land acquisition. And some customized Python software to generate useful maps for me.

  • Modeling and Simulation. This is software, written in Python. See, for example, Randomness and Inspiration.

  • Manuscript. The main writing is in Scrivener. This includes character and location details, the general outline, comments, notes, ideas, stuff, links, reference pages, research, and a lot of other stuff. Even my query letters are in the project binder with the main manuscript and everything else.

While an all-in-one-app approach is helpful, it isn’t always optimal. Even though I’m pretty seriously committed to Scrivener, I don’t use it exclusively. I haven’t gotten used to its outliner, yet. I spend a lot of time in Omni Outliner arranging and rearranging. And, of course, the cartography happens outside Scrivener.

I do like the binder. I like the sophisticated search alternatives. I use the various Synopsis and Notes sub-windows. I have to say, the floating Quick Reference windows are perhaps the best thing ever.


If you’re starting, pick a tool you understand. I wandered from a simplistic tool to a custom-crafted toolchain to Scrivener. I’ve had a lot of experience with complex, high-powered software tools, so it wasn’t hard for me to make the adjustments required.

Even though parts of Scrivener are easy to use, there is a lot there, and it can be overwhelming. Time can be wasted customizing the tool instead of actually writing.

I know people who throw up their hands and say “I don’t want all of this, I just want to write.” Good. Use TextEdit on the Mac. It works. You can get started. The Mac OS Notes app may be even better for capturing the flow of ideas into snippets that can be arranged and rearranged.

I also know people who replace writing with a lot of tool-chain fooling around. They have long lists of software to install and upgrade, and complex processes they impose on themselves instead of writing. Not Good. Write first; install tools later, when you need them.

Manuscript format for fiction is relatively easy to produce: it’s not the first thing to worry about. In most tools, there are a few simple settings to produce double-spaced 12-pt Courier. If your book is in Notes, you’ll have to copy and paste into something else. That’s busy-work after the writing.

For me, describing a complex hero’s journey, it works well to use an outliner with a lot of flexibility. There are nested entanglements, pending problems, and unresolved issues. I’m sometimes tempted to create more sophisticated metadata for the arc of each character’s journey and collect those arcs into a simple database where I can examine the details from a number of perspectives, eventually resulting in the raw material for a novel.

(This is a very attractive nuisance. I could spend a lot of time on this.)

Sometimes I have notes about timing and distance. I like to get those things close to right, so I create separate spreadsheets to track travel.

What’s important for me is to have a place to capture notes and stray thoughts outside the main text of the manuscript. I’ve got many of those places: inside Scrivener, Omni Outliner, Numbers, and Notes. The spreading is a potential problem. But I’d rather have more tools than have an idea and no place to capture it.