| Articles | 4 min read
For some time, I've been cogitating about redrafting my first novel, Weaver of Dreams and earlier this month I finally got around to starting the process. Revisiting an old, and arguably an important work from my formative years as a novelist, has been both challenging and interesting.
I've long felt that my original edition was structurally broken. I also made a lot of compromises due to time constraints and what was to be the intended audience, my then twelve-year old sister. I'm also 11 years older and like to think that I've improved since then. As a result, this endeavour has become more like a rewrite than the redraft I was expecting.
I decided to start again from scratch and rewrite the story using the tools and techniques I now have at my disposal. That means moving it out from Scrivener and going back to the structural drawing board.
Quite by accident, when searching posts about other people's Dropbox-based writing workflows I came across Matt Gemmell's excellent Writing a novel: resolving plot issues. I came across it just days into my planned start to the re-draft that I bought the eBook version. I instantly connected with the material and decided that I would try it and that's what initiated the complete re-write.
Essentially it provides a way to fix an existing project's structure in much the same way as the Snowflake method, helps you structure a new project the right way to begin with. I heartily recommending buying Matt's ebook version of his blog post; it's only $5USD and the extra content you get is well worth it.
My only issue was that the workflow depended rather heavily on OmniOutliner even to the point were the book shipped with several great templates. While I think OmniOutliner is great, I didn't want to lock such important files away in something that is proprietary, and didn't play nicely with the cloud services I prefer to use. If I went all in with OO, I'd need to buy it on OS X, iOS and use Omni group's sync service. For similar reasons I didn't want to use Scrivener or Ulysses. I don't have a problem with proprietary software but if I buy software then it must use an open format first and foremost as its native format and no, an export function won't do.
So after playing with the OmniOutliner trial, I decided to recreate Matt's templates in pure markdown. It's worked remarkably well; in fact it works better than in OmniOutliner. On the Mac, I use MultiMarkdown Composer with a custom CSS template that I designed to mimic the look of Matt's templates. I also used the CSS content attribute to auto generate scene and chapter numbers, something that wasn't immediately obvious how to do in OmniOutliner. The nice thing about using CSS is that that chapter and scene numbers only appear in the rendered output and they renumber automatically when I move scenes and chapters around.
As for the structure, I made slight changes to work better with markdown. When you export an OmniOutliner document to OPML, it treats all nodes in the hierarchy as heading level items with the exception of notes, which it turns into paragraphs. I found that messy so in my template I only use three levels of heading as follows:
# Document Title ## Chapter Title ### Scene Title * Scene points * Scene points
Scene points/notes, are just standard markdown bullets, which get rendered as an unordered list. I keep the scene title short and succinct and these get turned into filenames when I turn the outline into the physical project structure.
Because I use Markdown, I also get access to critic markup's features and I use them extensively to highlight, add or delete text. The comments feature makes a pretty good candidate for adding tags and notes because they can be styled or hidden in your rendered document but visible (and highlighted) in your editor view.
I can also make use of snippets that quickly generate chapter blocks ready to edit. Moreover, being plain text it's very easy to sort and manipulate the text with an editor's built in processing functions or writing your own with python. As for the editors themselves, the choice is legion so I'm free to pick what's best for the platform I work in or the task I'm performing.
As for the file itself, I store that in Dropbox to keep them in sync across my devices.
That brings me to my next change: Dropbox. I've long had a Dropbox account but have only really used it to share files with others. For my own documents I instead used my own instance of ownCloud. Since getting an iPad however, I've made a major shift to Dropbox because 1, it's much better at sync than ownCloud and 2, most of the best text editors on iOS work very well with it. By contrast, almost nothing on iOS (or Android) works particularly well with ownCloud. Dropbox also works very well with Linux, whereas it's competitors Google Drive and OneDrive do not.
So in many respects my environment has at last fully matured. Everything I do is now text (markdown) based. Projects are managed on the file system with scripting and multimarkdown transclusions where needed. Dropbox allows me to extend and synchronise that project structure between my desktop (OS X), laptop (Ubuntu Mate), phone (Android) and tablet (iOS). Four different devices, four different operating systems all sharing content in one common format which I can edit using the best-in-class editors for each of those devices.
In my next post, I'll further detail how this environment and my methodologies are now working for my writing and worldbuilding projects.