Writing in Plain Text
If you’ve heard of Markdown, reStructuredText, Textile, LaTeX, Fountain, or any one of the many flavours of plaintext markup language out there, then you probably already know that these are all different ways of using plain text to represent richly formatted documents.
Today, I’d like to talk about the why behind these languages.
As a writer and a geek, it’s easy for me to lose sight of just how tough a sell plaintext markup languages are for your average wordsmith.
In my own circle, everyone uses Markdown—my writing colleagues, the publications I write for, most of my writer friends—but when you have a conversation with someone who is used to writing in Word or FinalDraft, you realize that the benefits are not at all obvious.
This is counter-intuitive: after all, if a writer wants to focus on writing then what could be more pure than plain text? It’s as simple as it gets.
There are a few dimensions to this discussion, and most of them stem from my attempts to explain to writers who aren’t familiar with the concept why I opt to work exclusively in plaintext.
I use Markdown, so I’ll use that as the example syntax throughout this article, but the principles apply regardless of which language you prefer.
I’ve found that the best place to begin is on paper.
Plain Text is a Paper Notebook
Before computers, writers used pens and wrote on paper. Many still do.
Interestingly, these writers seem to get Markdown more readily than their Microsoft-Word-wielding contemporaries. If you think about it, the workflow and mentality of writing on paper is very similar to plain text, and only the medium differs.
Plain text writing has three basic goals:
- Separate writing from publishing
- Keep writing file format and platform agnostic
- Facilitate exporting to any required format Let’s examine these goals.
Before plain text writing became popular in the digital realm, focus was often the first casualty in the battle between word processors vying for your attention.
Lots of bells and whistles meant you could spend more time whistling than writing, which defies the core expectation a writer has for his/her tools. A writing environment must facilitate writing.
When you’re writing on paper, all you have is the text. No fonts, no formatting beyond your own cursory indications, and no distractions from the process of getting the words out of your brain.
Plain text writing works the same way, by acknowledging that it’s easier to be productive as a writer if we minimize distractions during the writing process and break off the stylistic considerations into their own, dedicated stage of the workflow—they deserve our undivided attention when we’re ready for that.
This isn’t to say that aesthetics don’t matter while writing, and that’s why plaintext writing apps differentiate themselves by providing various levels of control over the look of your writing environment, from none (iA Writer) to an entire theming system (Ulysses).
But even the most robust set of preferences will only allow you to affect the appearance of your workspace.
The words you fill it with are still plain text.
Banishing Proprietary Formats
Most dedicated word processing apps have their own proprietary file format, which may be more or less open to third parties who wish to convert to and from that format.
The problem with this system is that it requires the presence of a compatible app. It adds a layer of complication to simple things like sharing a draft or editing a document from your phone.
Whether you’re working on a Mac, PC, or Linux computer, a mobile device, or a web service, plain text will work. You can edit it using any text-compatible app under the sun, including the default ones without fear of strange formatting issues or conversion problems.
This means you can share it with anyone through any means without worrying about compatibility. It’s liberating.
Furthermore, many proprietary file formats include a tremendous amount of additional information pertaining to styling that isn’t relevant in the writing stage but causes the file sizes to balloon.
As a simple example, let’s look at a previous post on Inbox Zero. It’s about as simple as can be: no images, straightforward structure, and moderate length. It’s written in Markdown, which means it lives as a plain text file in my Dropbox.
inboxzero.txt weighs in at a lean 7KB.
That same article —with no added formatting—as an Apple Pages document is a staggering 331KB. In other words, the equivalent Pages file requires more than 40 times more space for the exact same content! That’s 40 times more data I need to use if I want to download and edit that from my phone while I’m away.
To be fair, what we call a “word processor” is really more of a publishing tool these days, and for certain workflows that makes a lot of sense. Not only that, but as long as we’re talking about files in kilobytes, we’re in no danger of filling up modern hard-drives.
That being said, it’s inefficient in principle, and if the goal is to focus on the words then I see little sense in dragging the rest around through the editing stages as well.
Like paper, plain text is portable, and utterly indifferent to the ultimate publishing destination of your words—which brings us to the third and final goal of plaintext writing.
A Markdown document is a file with nothing but your words and the minimal notations that the syntax uses to help you define structure and emphasis.
As a result, exporting becomes a breeze regardless of destination. Separating the writing from the publishing means that when you’ve finished with the words, you can really focus on the presentation with your full attention.
Depending on the app you’re using, you can define precise styles for PDF export, save as a native Word document for your old-school publishing needs, quickly copy everything as standards-compliant HTML for the web or RTF for email, render out an ePub for ebook publishing, or even create a workflow to automate the preparation of a book for the Kindle store.
In the first paragraph, I mentioned a number of plaintext languages other than Markdown. Many have extremely similar syntax for the basics and differ only in the scope of what you can designate.
Some people prefer alternatives, but I’m a fan of Markdown for the same reason I’m a fan of Dropbox: it’s simple, reliable, and ubiquitous.
Writers are picky, and many refuse to try a “coding language” on principle, but Markdown barely qualifies. In the shrewd words of Brett Terpstra, “The syntax is so simple you can barely call it syntax. If you can use an emoticon, you can write Markdown.”
Not only that, but almost every Markdown editing app uses the same keyboard shortcuts for formatting that you’re already used to, and will display your markup directly—bolded text appears as bold, etc. It’s just as visual but you have the advantages of working with plain text.
Assuming you give Markdown a try and spend the ten minutes it takes to learn it inside and out, this opens up a wonderful world of apps, services, and tools for writing or editing or publishing documents. Keep your eyes peeled for a future article where I dig a little deeper into the specific Markdown editors and other tools that I use and recommend for writing.
Perhaps the best thing about this subject is that your choice of plaintext syntax language is actually not very important: the files you make will still be plain old text files, and since the syntax is so similar it’s often trivial to convert between languages.
This brings us to the question I set out to answer: why would someone consider adopting a plaintext workflow?
For starters, I don’t think it makes sense for every possible writing task. In particular, drafting documents that require extensive use of editable tables will benefit from a workflow that provides tools for that, and plain text simply doesn’t—even via some of the markup languages that support tables.
For the rest of us, I’d argue that working in plain text makes a lot of sense. Not just bloggers, but novelists, researchers, screenwriters, and others who value speed, focus, and flexibility in their workflow.
For me, the advantages are the following:
- I can focus on the words while writing or editing, and worry about styling later
- The styling is marked up in a neutral manner, so I can export the same document using ten different styles without needing ten different copies, each with its own settings
- My work is easy to transport, save, share, and back up with minimal effort
- I’m saving in the closest thing to a future-proof format that’s possible in the digital realm
- I can use one master file to export to any number of different destinations
- I can automate parts of my workflow like publishing to a site or exporting to several destinations automatically Plain text writing can be applied to any workflow, platform, and destination, which makes it very flexible.
It may not be for everyone, but if you haven’t given it a serious try yet, I encourage you to do so—you might surprise yourself with how much of a difference it can make for your productivity.