I hate this way of making things. When I work on a talk
, I write a bit, but soon I also make a few early slides, then I practice, then I write some more, and so on. The act of making the visuals, and the early pained performances – in other words, prototyping
the talk – come back and inform what I actually want to say.
This process can be unnerving. Any project done like this very quickly feels “almost complete,” even if a lot of work and polishing remain. It can be meandering, too, tangible milestones replaced by structureless, incremental progress.
But it’s also really fun. You don’t sketch a bike, then pick a paint from a catalogue, then email both to a bike maker and wait for results. No, you grab two wheels, slap them onto a frame, and even though it doesn’t quite feel safe, you start riding, see how it feels, and repeat and repeat over again, as a more and more complete and unique bike manifests itself around you.
I do the same writing software – thinking and making interleaved – and I wanted to repeat this process here. I didn’t want my photos or the book’s typography to feel like rushed afterthoughts. They felt like the crucial part of the book’s storytelling, and they needed to coexist with emergent text as soon as possible. I also wanted to feed off of the energy of seeing, holding, reading my prototypes.
Plus, I hated the idea of locking my book into InDesign at one arbitrary moment in time. I knew that editing in InDesign can be incredibly unpleasant – it lacks the speed and hard-won nuances of word processors – and I wanted to continue writing in Scrivener, and to preserve the freedom to output my book in HTML, or Markdown, or any other format I could imagine.
But, then again: 888 text boxes, 381 image captions, 584 footnotes. The notion of spending days if not weeks flowing them into InDesign every time I wanted to see the newest prototype seemed daunting. So, I decided to do that foolish thing technologists do: I threw code at the problem.