Markdown for NaNoWriMo and beyond
Doing NaNoWriMo? Want to focus more and produce more words? Think you might want to publish your book someday? If you’re a writer who answered “yes” to at least two of those questions, this blog post is for you! I’ve encouraged writers to use Markdown before, but Markdown can be especially helpful to a “WriMo” (NaNoWriMo participant) with visions of publishing. It lets you focus on your writing instead of quirky software, and it ensures that your manuscript is clean when it comes time to preparing it for publication.
What Are You Really Writing?
When you’re writing a story, you’re not writing fonts. Or margins. Or tab stops. Or page size. Or italics. You’re writing a story. That story starts out in your mind and makes its way onto paper or into your computer. This is not far from how software is developed: A programmer starts with something in his or her mind and then creates it on the computer. What they create is (usually) not usable by you directly, it has to be “compiled” into a format that works on your computer or mobile device. The programmer creates the “story” (source code) long before the “reader” (user) sees it.
When you think of typing your story on your computer as creating the “source code” for a “program” your readers will enjoy later, it will start to make sense that you should use tools that are focused on creating the source code, not tools focused on providing a completed product for readers. “Compiling” it for readers comes later, and anything you do to prepare your "final product" during the first draft can actually decrease the value of that product. For this reason I will say again what I have said many times before: A word processor is not the right tool for writing books! (It’s also not the right tool for publishing books, but that's a topic for another blog post.)
Meaning vs Style
Want me to scare you away? I could say, “Markdown is about semantics.” How about a less scary version: “Markdown tells the computer how to display your story to readers.” Instead of thinking about the style of the text, you think about the meaning of the text. In this context, “the meaning of the text” refers to how the different parts of the text relate to each other, not the story meaning. For example, consider this micro-story:
Mittens, that old alley cat, killed and ate the terrified mouse.
The story meaning is that a certain feline consumed a scared rodent. The meaning of the text that I am referring to is that a subject, identified by a proper noun and adjectival phrase, completed a compound action on an unnamed object, and that one part of the compound action should be emphasized.
When you’re talking to someone, none of your words are “italicized” but some of your words might be emphasized. The same is true when the story is in your head; those words have the “this is emphasized” meaning, not the "this is italicized" meaning. With a couple quick keystrokes using Markdown, you can tell the computer about that meaning. Much later, when it’s time to publish, the connection can be made (if you want) between emphasis and italics. There’s no need to think about it when you’re drafting or editing your story. The same is true with text meanings such as “this is a long quote” or “this is a chapter heading” or “this is a flashback to childhood.” You want to retain the meaning that was in your head when you thought of the story, but you should not yet focus on how it will look to the reader.
Defining Rich Semantics
If you know just a little HTML and CSS, you can mix those into your Markdown. A good example is where want to specify a meaning (semantics) for something that doesn’t exist natively in Markdown. This can be set using a simple SPAN tag (HTML) with a CSS class. For example, Markdown might not have a way to specify “author’s name” but that doesn’t stop you from defining how author names should look. You could use HTML and CSS like this:
This blog post was written by <span class=”author-name”>Stuart Whitmore</span>. Every time you want to use an author’s name, you would surround it with the same code. Later on, when you’re not focusing on writing, you could specify the style you want applied to all author names. Bold! Red! Blinking! Uh... blinking? ("Did you say Abe Lincoln?")
You can mix these approaches. For example, let’s say that your book includes sections of text that are the main character’s thoughts, unheard by other characters. If you thought “put the character’s thoughts in italics” you’re thinking about content style, not meaning. To focus on meaning, you could plan to define a CSS class for character thoughts. Some of those thoughts might need to be emphasized, the styling of which you would also decide on later. Here’s how that might look:
<span class=”mc-thoughts”>I wonder what that idiot wants *this* time.</span> This mixes the emphasis meaning (Markdown asterisks) with the thoughts meaning (CSS).
Here’s an example of how your story might look in a word processor:
Jim looked at the sign over the tavern door. Punch Your Face Saloon. It seemed a little foreboding, but he assumed it was a joke. Boy, was he wrong.
Here’s how it would look in a plain text editor with semantics added in Markdown:
Jim looked at the sign over the tavern door. <span class="sign-text">Punch Your Face Saloon</span>. It seemed a little foreboding, but he assumed it was a joke. Boy, was he *wrong*.
If you can find your way to the * character on your keyboard, you can emphasize text without clogging your story’s “source code” with publishing style information. Markdown does more than emphasis, of course. You can do numbered and unnumbered lists, insert illustrations, create quote blocks, and more. Plus, if you can write a little HTML and CSS, you can define countless ways to indicate how some sections of text relate to others.
I Just Want To Click A Button
If you think “well, it’s easier to just hit Ctrl-I or click the italics button,” you may be right in the very short term, but you’re causing work and/or grief for yourself in the long term. Look at the benefits of using Markdown instead of using a word processor (especially using one the wrong way, i.e., without using its style features):
- Prevent stray formatting (style) instructions from causing broken formatting in your published book which may not be noticed until after you’ve published it.
- Quickly and easily change the way something looks throughout the entire book by changing the style definition once, instead of looking for each instance and hoping that you find them all and change them all the same way.
- Allow automated conversion tools to generate multiple formats from your “source code.” This is much more effective, and much less error-prone, when you start with a clean source. The old “Garbage In, Garbage Out” rule applies to automated conversion tools, and a source cluttered with style instructions can become “garbage” if you don’t have close control over those instructions (and most word processors do not give you close control).
- Ensure semantic consistency. Assuming that you're writing a fairly long work, such as a novel, over the span of more than a few days, you might forget that you started out styling certain text one way and then change it mid-draft. You would hopefully notice this before your work was published, but fixing the erroneous styling is a waste of your time. If you instead mark that text with it's meaning (relative to the rest of the text) you don't have to worry about consistent styling. Using the "character thoughts" example, you won't forget mid-draft that it's a character's thoughts, but you might forget styling specifics.
The learning curve for Markdown is very low, especially for a work like a novel where you might not need document features that are common elsewhere (numbered lists, hyperlinks, multiple levels of headings, etc.). The minimal effort to learn Markdown will pay for itself later when you can rapidly, and correctly, convert your "source code" into MS Word documents, PDFs, ePUBs, HTML, and more. Give it a try!
About the Author
Stuart J. Whitmore is an author of fiction and nonfiction, as well as a photographer, technology developer, and more. If you enjoy reading his blog posts, you might also enjoy reading his books. Take a look at the books by Stuart J. Whitmore today, and download your copy of one that looks interesting to you!