The process of writing a series of interlocking novels is a bit odd when compared with writing a single novel that stands alone. To begin with, you have to be able to adjust the timeline a little bit whenever events in one book take too much time to fit. This is, of course, the easy part. The true misery comes when all of the software you’re using to create the book gets discontinued during the course of the project, thanks largely to the almost geologic time scale involved.
Thus goeth the life of a writer.
This article is the first of several articles based on my experiences while releasing the electronic and print editions of the initial trilogy in my Patriots book series. In it, I talk briefly about writing the novels and the various challenges involved in writing a series of books over the course of more than a decade. Stay tuned for additional articles about eBook publishing, affiliate programs, and print publishing.
If you ever think about writing parallel plots, my one big tip is this: don’t. If you choose to ignore that first advice, you’re going to need to do a lot of planning. There are a number of ways that one could approach this, depending largely on whether you’re a natural organizer or not. As someone whose idea of organization involves a temporally organized stack (with the most recently referenced paperwork on top), you can see where this could be a problem.
The first and second books were no big deal, because the second book was written from the perspective of characters who didn’t really interact with the characters in the first book until the very end. The second book also referenced a few major events, but otherwise wasn’t tightly coupled to the first book in any way. The third book, however, proved to be a much bigger challenge because it borrows bits of the first story and uses them in a larger narrative. That means that the second half of the third book (give or take) is very tightly coupled to the first book.
Being a programmer by trade, I approached the coupling problem using a programming methodology: tagging. Specifically, I decided on a system of markers to indicate that certain content should be treated as comments, and thus should be printed only in draft copies—in my case, three at symbols in a row for the beginning and end of each comment. I sprinkled these liberally throughout my first book. Then, every time I had a section that began with a time indicator like “the next day”, I recorded the date in a comment.
From there, it was relatively painless to go through the comments and make a timeline of events. This also made it relatively easy to adjust the timing of events in the first book when needed to accommodate the events in the third. Of course, I still had to make all those changes to get things to line up correctly. (Did I mention that my one big tip is “don’t”?)
Of course, the last step was to remove all those markers after I was reasonably confident in the timeline. That’s the point where it helps to know how to write software.... Fortunately, I designed my own publishing system, so I translated those comments into special tags that I could turn on or off. In my draft copies, I printed the comments in red. In final copies, I didn’t print them at all. This made it relatively painless to work with those comments. Honestly, I wish I had done that much earlier in the book’s development, because it would have saved a fair amount of effort.
When most people think about starting a project, they think about how many weeks it will take. With this project, the question was how many years it would take. The answer turned out to be fourteen. During that time, I was not only writing and editing the books, but also designing the cover art, crafting some of the fonts, creating the publishing toolchain that I used for producing PDF, EPUB, and MOBI files, designing the website, and so on.
The first big mistake I made in the writing process was my choice of editing software. When you choose a piece of software, it is important to choose something that will still be available and supported when you expect to finish that project. For a book series in development for fourteen years, that’s a bit of a problem. You see, none of the commercially available Mac software from fourteen years ago will run on a computer today without updating to a newer version. Worse, most of them don’t have newer versions available.
When I started writing the books, I used an office suite called AppleWorks, made by Apple (what a surprise). Two years later, with the release of Keynote (which duplicated functionality in AppleWorks, albeit in a more polished form), the future of AppleWorks was in doubt, but it was at least still usable. Eventually, Apple replaced the word processing parts of AppleWorks with a new app, called Pages. Unfortunately, switching to Pages was not viable for a variety of technical reasons.
My legacy publishing workflow is fairly straightforward. I use the HTML export feature of AppleWorks to produce badly broken (but consistent) HTML. I then run a tool that fixes most of the unmatched HTML tags, and a second tool that converts that mostly matching HTML into DocBook XML (with various extensions). From there, I convert the XML into PDFs using DBLaTeX, and into EPUB books using custom tools.
The problem with that workflow is that you have to be able to usefully interpret the HTML output from the editing software. The HTML output from AppleWorks was abhorrent; if you had italics tags that spanned a paragraph boundary, it would gladly start the italics in one paragraph and end them in another. But at least it used HTML tags. Newer editors, like Word, Pages, TextEdit, and so on, use CSS styles to represent italics, fonts, and so on. This means that instead of being able to quickly map an italic tag onto a different italic tag in the output XML, you would instead have to examine the tag, parse the CSS, interpret all the selectors, figure out which ones apply to a particular span tag, and then emit a series of tags.
I tried to implement the translator at one point, just to see if I could make it work, but I quickly concluded that it just wasn’t feasible.
Then, the other shoe dropped. Apple changed from using PowerPC processors to Intel processors. Because AppleWorks was discontinued at that point, Apple never released an Intel version. For a while, Apple provided an emulator, Rosetta, to let you run old PowerPC apps, but they dropped that support in OS X v10.7. At that point, I was still almost four years away from my release, with no practical way to upgrade to newer versions of OS X.
For the first year, I kept my laptop running 10.6. Eventually, however, I started having to deal with other software that wouldn’t run in 10.6, so I was forced to upgrade. I ended up building a virtual machine with 10.6 Server running inside it so that I could keep running AppleWorks for incorporating the last few rounds of edits to my book. It was a horrible hack, it was incredibly buggy, and it crashed frequently, but it got me through.
If that were the only problem, it would have been enough, but the big nightmare hit when Adobe discontinued sale of its flagship image editing software, Photoshop Creative Suite, upon which my cover art depends, in an appalling attempt to force everyone who uses their software to rent it on a monthly basis for far more money than I typically spent to buy upgrades every second or third version. I made every effort to move to an alternative, Pixelmator, but there were enough typographical issues that it would have taken far too long to move the content over.
Fortunately, Photoshop CS6 still works, so I was able to continue working with it for the time being. I will probably do all future covers in Pixelmator, but I’m starting to have serious doubts about whether I can ever put my trust in closed-source software again—whether I can ever trust a closed-source software vendor to maintain the software that they release. That’s the thing about trust: Once someone has lost your trust, it is very hard to earn back.
And that wasn’t the first time I got burned by Adobe. At my former workplace, we used FrameMaker for authoring books, and I seriously considered moving my books over to it—so much so that I actually created some preliminary tools to do the conversion. Fortunately, I decided to hold off and wait for a native OS X version of FrameMaker before taking the time to polish those tools and commit myself to that path. Adobe dropped FrameMaker for Mac in 2004.
So strong has my distrust of the software industry become that I am writing all my future novels in DocBook XML (with a few custom extensions). I ended up writing my own semi-WYSIWYG XML editor to make life a little easier, but the fact is that Apple could go away tomorrow, and I could finish writing and editing my books in vi, and build the books in Linux. My book projects are now entirely under my control, so no decision by some random middle manager in some random company can leave me powerless ever again.
And that’s just the way I like it.
Keep reading in Part II: Electronic Publishing (Herein lies the path to madness).