Ordinary Human Language

by Brian Crane

Outputs, or Some Thoughts on Export

The simplest way to organize a text is to pick up a pen or pencil and to write it on a piece of paper. You can put information where you want it to be and, within the limits of the tool you’ve chosen, format the various pieces: an underscore here, calligraphy for the title, thick block capitals there. Typewriters work the same way with much less flexibility.

Computers allow for greater flexibility in theory, but how much you have in practice depends upon the application you’re using.

Word Processors

Microsoft Word and other word processors offer the least flexibility. Yes, drafting is much more flexible than on a typewriter and revision is much easier. There are also many typesetting options: fonts, text alignment, images, etc. Importantly though, as with the typewritten or handwritten page, in modern word processors the presentation of the final printed document is determined by the presentation of the draft on the screen. What you see is what you get.


Scrivener offers much greater flexibility by making a significant departure from the word processor model. In its projects, the formatting of the draft is independent of the presentation of the final product. You write and revise using the fonts and file hierarchies you find useful. Then when you are ready to export (or “compile”), you tell the application what to include from your draft and how to present it. The compile options available are extensive, and yet, in my experience they are rarely overwhelming. The only challenge most Scrivener users will have is figuring out which of the many options they actually care about (so that they can ignore the rest). The profound confusion that leaves people immobile and unable to move forward with a project is rare because, despite all the changes it introduces, Scrivener’s end product is always the (sometimes virtual) printed page, an output format extremely familiar to every user. So its many options operate within a well-understood boundary.


Tinderbox offers even greater flexibility. Like Scrivener, it assumes that your working documents and output file are independent of each other. But unlike Scrivener, it does not assume that your output will be a printed page. It can be and for many users will be, but Tinderbox accepts that some users may instead wish to generate a large set of interlinked HTML files that will be rendered in a browser. Others may want to generate a plain text file containing thousands of lines of comma separated values that will be read by a machine rather than a person. In Tinderbox, these output possibilities (and nearly anything else you can imagine) are all equally possible: if you can explain what your output should look like, Tinderbox will create it for you from your notes.

In practical terms, this means that, when drafting in Tinderbox, you operate with a freedom similar to that found in Scrivener: you write, you revise, and you organize using the practices and principles that make sense to you without worrying about output. When you are ready to output though, the two applications function very differently. In Tinderbox, when you want to generate some kind of document to share, the application doesn’t make assumptions about what you want (as Word and Scrivener both do). Instead it asks you to tell it what you want it to create from your notes.

Telling Tinderbox what output you want is export, and you do it with templates. (Which are a lot like Mad Libs.)

Posted July 8, 2017