How I learned to hate InDesign

Quick updates first: 

A few weeks ago, my coworker tweeted this:

An abandoned typewriter is not a rare occurrence, and this one was just another boring wedge. But I looked it up anyway, and recognized that this particular unmemorable typewriter – Olympia Electronic Compact – had a particularly memorable Enter key.

“Can I have that Enter key pls,” I responded. “Left the beach already but totally woulda grabbed it for you!” she wrote back. But San Francisco is a small city, and catching a bus to its only real beach wouldn’t take very long. “Can you tell me where it is?” I asked.

She replied with a set of coordinates: 21°16'56.6"N, 157°42'51.6"W. I looked them up while preparing to leave the apartment, but I never put on my second shoe. 

I forgot my coworker was abroad. The typewriter and its unique Enter were not in San Francisco, but over 2,000 miles away, in Hawaii.

Every keyboard is a puzzle. There are this many functions, this many keys, and – particularly these days – only this much space. For reasons that bother some and enchant others, QWERTY is basically untouchable and has been since the 1880s. Around the perimeter, though, anything goes. You see arrow keys contorted into strange layouts, fused with the number keypad, awkwardly sticking out. You see Fn deployed to take on responsibilities of its removed comrades. You see less fashionable keys simply disappear.

But what’s most fun to watch is Enter. Back in the days when the carriage return was still most often a lever, typewriters sometimes left a hole, filled by the Enter key only in the more expensive models.

Holes like this don’t happen anymore – every keyboard is a city struggling with overpopulation, with no inch left unaccounted for. But it often does feel that Enter fills the space remaining after all the other keys are laid out. I’ve read studies that said that the classic reverse L shape is most friendly for the fingers. And yet, you don’t see that expensive shape very often. Instead, most Enters – entirely vertical or horizontal, maybe with tiny appendages – would be a blessing in Tetris. Throughout history, only some came with peculiar bodies.

I have been obsessed with Enter shapes for years now, and I thought having a little visual montage would be a nice addition to the chapter about keyboard layouts. I was hoping that by just scouring my nascent keyboard collection, I will find 4–5 interesting examples: a straight one, a crooked one, a weird one. 

When I finished prying Enters from keyboards just around me, I counted nineteen. That was two years ago.

Every book is a puzzle, too. There is this much text, this many footnotes, this many image captions. Space constraints are there, as well, but more complicated. The rectangle of the page has its obvious physical limits; you can always add a new page, but then you inherit an extra one that too needs to be filled out with something… and, of course, you can’t continue adding pages ad infinitum. 

A chapter in my book needs to start on the right-facing page, and end somewhere near the bottom of another right-facing page. Image captions have to be near images and footnotes have to be near their respective passages, although those “near”s are malleable. No boxes cannot overlap, except if on purpose (for example, image captions can go on top of some images if they remain legible). Various laws govern how wide or how narrow a text box can be before reading it becomes hard on our eyes. 

Everything’s connected – adding just one character can have serious cascading effects and unbalance the entire book: the whole paragraph moves to the next page trying to avoid an orphan or a widow, an attendant image needs to follow and pushes another image, the footnote that was previously safe now has to negotiate its space with a new contender.

And the number of boxes is an order of magnitude higher than key counts on even the largest keyboards. In the current state of the book, there are 888 text boxes, 381 image captions, and 584 footnotes.

The traditional way of making a book consists of discrete phases: you write the manuscript in Word or Scrivener, and then rewrite with your (human) editor. After that, you grab photos. Then, you send all of this to the publisher, where a specialist takes your final text and your final photos, chooses the proper fonts and templates, and then solves the complex puzzle of many boxes. The text, footnotes, and images are flown into rectangles in InDesign, the industry-standard typesetting and printing software, and the result is tweaked by hand as necessary. If there are any last-minute text or photos changes – which is highly discouraged – they’re made directly in InDesign.

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.

The idea was simple. Instead of arranging boxes by hand, I would write software to do it for me. It was a bit like the movie WarGames. I created a WOPR, but not one that was constantly imagining military conflicts and their outcomes, but instead one tasked with a much more prosaic problem: what if Marcin wanted to take his book to the printer today?

This meant taking all the creative decisions that I would’ve made, and expressing them in code, so the book could be automatically assembled over and over again, even as I was still editing the text and adding new photos. 

“The footnotes should be on the right hand side, except for the first page or the last spread of a chapter,” “Two-page spreads should have their image captions on the next page,” “Pages with images at the bottom should not have footnotes” and myriads of incantations like that were now lines of JavaScript. Instead of me putting an image next to the appropriate portion of text by hand, any paragraph could now say “I want this particular photo somewhere near me,” and my code would listen to it and do the rest: lay out the photos, resolve space conflicts, make sure nothing overlaps, overflow footnotes to subsequent pages if necessary – and warn me when things couldn’t be solved automatically, so I could code a new rule to account for that.

I exchanged the effort of laying out thousands of boxes over and over again for writing code that would do that for me. But I underestimated how hard of a problem this actually was – effectively, I was writing a constraint solver without any prior experience building a constraint solver. The chore of laying out boxes over and over again was gone. But what replaced it was the chore of writing and improving thousands lines of code, dealing with hundreds of bugs, and – the worst part – something I did not predict at all: the incredibly, violently, disturbingly unpleasant process of writing code for InDesign.

I tend to be obsessive. Even though 19 Enters in the book was many more than I originally intended, I didn’t stop there.

In the months since putting up the first Enter collage, I got quite a few new keyboards. Every one that came with an interesting Enter saw that key removed, photographed, and inserted into the collage:

This was pleasant and rewarding. It feels great to complete things, to improve them. This was the legendary “flow,” celebrated by Csíkszentmihályi in his famous book, and millions creative people since.

Coding is supposed to be the same, and often is. “Code soothes because it can provide control in moments when the world seems to spiral,” wrote Craig Mod recently. But InDesign never got the memo, and proved an awful partner. It was slow. Its JavaScript had been frozen in time in the late 1990s. Its coding was poorly documented and its community sparse. Its footnote engine was so embarrassingly limited – the footnote had to be on the same page that its symbol, all else be damned – that I had to write my own. And it had so many awful quirks that couldn’t wait to become so many awful bugs. 

Just as coding can be rewarding, fixing bugs can be fun – lowering a drawbridge between people and machines, restoring order to the universe, solving a tantalizing mystery. Bugs can enlighten and teach. Just recently, I wrote about a bug in Figma that unearthed forty years of keyboard history. One of my favourite pieces of writing ever was reflecting on a hardware bug that made me the kind of programmer I am today. 

But once again, these bugs… oh, these bugs were different. At one point, my page 1 ended up on page 270, and I am still not sure why. At one point, InDesign crashed without ceremony doing exactly the same thing I asked it to do a few hours before. At one point, one of my footnotes had extra spacing at the bottom and it doesn’t anymore, but fixing it brought me no satisfaction.

This was root canal coding. InDesign’s scripting engine was so uncooperative I had to write not one, not two, but three separate circles of debugging. Even if my scripts grew complicated over time, their tasks were nothing that modern computers shouldn’t be able to handle within half an hour. And yet, many evenings I began the process of assembling the book, only to wake up in the morning to see my computer still working, its fans blaring – eleven, twelve, thirteen hours after it started.

Making a tiny mistake and having to wait overnight to learn about it was how computing was done in the 1960s. I did not anticipate living through this, some sixty years later.

I was now buying keyboards on eBay just so I could put more interesting Enters in my little collage, the number growing steadily all the way to 42. I found an Arabic keyboard so I could show the symbol going in both directions. I found one Enter with a rare label saying New Line (Enter keys were labeled Return before 1960s, and even today struggle with their identity). I grabbed a beautifully stepped key from a rare word processor:

Just like I hoped, collecting and laying out these Enter keys helped me understand things, and made me rewrite the relevant bits of text. The number of keys grew so large that I imagined writing a script to lay them all out on the page, achieving perfect optical balance. But learning from my experiences building my peacetime WOPR, I kept placing all of these Enters manually:

Because at the same time, I kept fighting for – and with – my book-assembling scripts. I spent weeks and then months of 2021 heading to bed hearing my computer starting its struggle in the other room, not knowing whether it would succeed, show errors, or crash even before it could show them.

Any given weekend felt like the weekend when it’d all be done, with the script close to reporting zero errors. But then, fixing one last error created an avalanche of effects on the rest of the book, and those had to be resolved as well. 

It was only two weekends ago, many weekends later than expected, that I woke up to this view:

I won, I guess, in the end. All the boxes are now finally accounted for, and another printed prototype is heading my way. The book will not change that much between now and printing, so I will never have to do it again.

But it is a Pyrrhic victory. What was supposed to be a cool, magical experience – seeing a book assembling itself in front of my eyes – ended up being a programmer’s nightmare. What seemed (and what should’ve been) a weekend’s worth of work stretched to a few months. I’m tired. I don’t know if I learned many lessons and I don’t know how I’d even approach it differently – the only viable competitor to InDesign doesn’t support coding at all. Even the idea of sharing what I learned – something I’ve done recently around another creative project – leaves me cold.

But when technology failed, people didn’t. Remember the strange Enter abandoned on a Honolulu beach? “Left the beach already but totally woulda grabbed it for you!” my friend said. I requested the coordinates, she cheekily complied, and only then I realized that at that moment in time, we were miles apart. 

But then, I talked a bit more about my infatuation with Enter keys, and an unexpected reply arrived: “we are going to go back and retrieve the keyboard!!!!”

She did. A week later, the beach Enter made it to continental America. A few days after that, I plugged it in. By hand.

This spread, celebrating a century of puzzles, itself a small puzzle within a huge puzzle, has 54 keys today. I am planning to never touch it again, and I plan to do as little coding for this book as I possibly can.

There is a photo I really like. It’s from 1937, showing a woman next to three Automatic Typewriters. This is the first time this kind of technology has been applied to writing, the true beginnings of word processing decades before Word and Scrivener.

The photo’s supposed to convey the wonders of automation. Three typewriters, and the typist has nothing to do! But at least this week, I’m reading a different vibe from the woman’s expression: an “are we sure we want to go this way?” hesitation.

I don’t usually have much nostalgia for typing before computers. I don’t usually hate coding. But after all my algorithmic InDesign travails, I wish I could grab an old typewriter, head out to the beach (in Hawaii or otherwise), and do nothing but write.

This was newsletter №24 for Shift happens, an upcoming book about keyboards. Read previous issues · Check out all the secret documents