Bro, do you even CMS?
Last week, I attended the ebookcraft and Tech Forum conferences in Toronto. At these events, BookNet Canada brings together editors, publishers, and technical staff to discuss digital publishing. This cute and useful flowchart explains the foci of these closely-linked conferences. For reasons both charitable and baffling, they invited me to speak about poetry formatting for E-books.
Moi, j’avais visité au Canada quelques fois déjà, par ce que j’ai des cousins qui habitent au Montreal et Quebec. Donc, j’ai beaucoup savoir faire au sujet des Canadiens—so just imagine my surprise when nobody in Toronto spoke French.
I arrived on Tuesday afternoon, and thus did not attend the ebookcraft hands-on workshops, so I’ll leave those writeups to others. I did attend the speakers’ dinner, where I was surrounded by friendly people. Many of these speakers were people I’d seen and admired at the Books in Browsers conference last fall, and some were people I’ve come to regard as colleagues via the weekly #eprdctn hour discussions on Twitter. Many of them seemed genuinely interested in my talk. Poetry may be a small fraction of the literary output of trade publishers, but it accounts for an outsized portion of the formatting headaches.
In addition to great food and company, the speakers’ dinner provided me with another analogy to the problem of choice faced by anthology publishers. Reds restaurant has a big menu of what I’m sure are good dishes. But to speed things along, BookNet Canada had Reds offer us a streamlined menu of three salads, four mains, and two desserts. With a few adjustments for dietary restrictions, the restaurant was able to make everybody happy and keep the attention on the event and the people.
Before I get to my notes on each talk, three things I should mention about the twin conferences in general.
- People were amazingly kind and gracious. People who are first-page Google search results for technical E-book questions were happy to say hi, offer insight, or team up for group icebreaker activities. I liked how cheerful, accessible, and professional the attendees were.
- The event ran like clockwork. The hotel was close to the event, the staff had the right checklists and name badges, the social media outreach was responsive, the food was yummy, and the A/V setup was seamless.
- The podium was enormous. Seriously, it was the biggest podium I can remember. Like deer and seals, podia follow Bergmann’s Rule: the largest specimens are found closer to polar latitudes. So up north in Toronto, speakers can find themselves behind a 1.7m podium, while speakers at conference in Cancun might only have to contend with a 1.3m podium. (Podia in New York, of course, are usually about 4′ 5″ tall, and some Boston conferences, in deference to local custom, prefer to use lecterns.)
Day 1: ebookcraft Morning Talks
Derrick Schultz, Atavist and EPUB Secrets, “Stone, bronze, iron, ink, silicon (or ‘I’m the laziest developer out there’)”
Derrick was giving two talks, one at ebookcraft and one the following day at Tech Forum. That’s a heavy lift, but he did a nice job here. His first talk explored why Web designers were big on Content Management Systems (CMS) and book publishers were lukewarm. (A Content Management System is kind of like Bisquick; one mixes up a basic batter and then makes waffles, or biscuits, or pancakes depending on what final product the customer wants. In this analogy, the author’s manuscript is the batter, muffins baked in little paper cups are are books, and savory crepes are iBooks on iPads Air.)
Derrick walked us through the evolution of Web design and content reuse. We started with hand-coded Websites, where each page was written ad hoc by a person. Other than copying & pasting some particularly useful code, each page was bespoke. Next came site templates and CSS styles. Then Web designers transitioned to php/MySQL calls, so a Web page can be assembled for a particular user or tailored to a specific device. Now many sites use APIs that can automatically fetch information from external sources. Derrick pointed out that with APIs, “It doesn’t even need to be your content. We’re letting machines create more of this Web.”
The not-so-secret secret about E-books is that they are little Web pages, written in HTML/CSS and stored (usually) locally on a tablet or E-reader. But book publishing as an industry has largely sat out these developments(1). Content (the words and pictures in a book) and presentation (how those words and pictures fit together on a page) are still yoked together in the workflows of many print publishers. As such the definitive, “final edit” version of most book manuscripts is likely to be in the layout files of InDesign (or QuarkXPress or even Pages). That’s ideal for ordering additional print runs or making minor revisions to a trade paperback, okay for reissuing a commemorative hardback or PDF version, and pretty terrible for making an E-book or large-print version.
After issuing a tongue-in-cheek “trigger warning” for E-book developers who scoff at the mere mention of the dominant page-layout program, Derrick pointed out that many publishers use InDesign as a jury-rigged CMS. “InDesign isn’t really semantic data; it’s a GUI/WYSIWYG for print.” That’s certainly true for us (more on that later). Derrick walked us through a few slides for Atavist to show us their CMS. More importantly, he showed us how one title could have different presentations and complexities on multiple devices, with (one hopes) a minimum of fuss for the developer.
Colleen Cunningham of F&W, “Tag Sale! A Case Study in Starting and Selling Semantic Tagging”
Colleen spoke later in the morning, but her talk was such a good pairing with Derrick’s that I feel it makes more sense to juxtapose them. Colleen and Derrick felt the same way:
— Colleen Cunningham (@BookDesignGirl) March 11, 2015
While Derrick spoke about the creative possibilities inherent in customizing and outputting content that was a good fit for specific devices (or paper stocks), Colleen focused more on the benefits and efficiencies for production and editorial workflows. From her point of view, it’s wasteful, error-prone, or even demoralizing for proofreaders to make edits at many different stages of a “book,” including corrections made after a manuscript has been “forked” into versions for EPUB, paperback, Kindle, etc. A spelling error in the Kindle version of a book very likely exists in the print version, but fixing that error across multiple texts can be a headache of accountability.
F&W uses a heavily-customized CMS they bought (licensed?) from Librios. InDesign still exists in F&W’s production department, but Colleen is in the process of moving as much of the editorial workflow as possible into the “Bisquick” manuscript stored on the CMS. A big part of that is training the editorial and production teams to tag their content, much like how we train our contributors to style their Word documents. The production team(s) also need(s) to think about metadata and licensing/permissions early on in the process. It is possible, for example, that an editor acquired print rights to a manuscript, but did not secure E-book rights. Similarly, a typeface designed for E-books may not have a perfect analog in, well, the analog world of print. Retraining an entire editorial/design/production workflow doesn’t sound like fun, but one can imagine huge benefits to learning early that a particular image is too expensive or a contributor is too obstinate for a particular project.
My main takeaway from these two talks was Oh man, we need a CMS like whoa, and finding one for a part-time small press is going to be a whole thing. Our current CMS at Bicycle Comics is my brain, aided by GMail searches and InDesign files. For poetry books, we “fork” our manuscripts way earlier than I’d like: at the stage of a well-edited RTF file. My print designers place that file into InDesign while I import the same thing into Dreamweaver. Any typos or revisions must be duplicated across both editions. Not fun. Not cheap. Not modern.
If we can’t implement a true CMS, we might at least try to improve upon our RTF file with something more structured, something that offers semantic tagging and easy pathways into InDesign and Dreamweaver/HTML. One possible solution could be Markua from LeanPub, which I wrote about last year.
More to come on the rest of the morning’s speakers!
1. At least part of that is because the tools for print development have also gotten better: in 1998, we were still using Adobe Framemaker, Adobe PageMaker, and QuarkXPress to create books. People who weren’t in publishing in the early 2000s can forget what a miracle InDesign 4.0 (aka InDesign CS2) was.