Notes on ebookcraft and Tech Forum 2015

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.

waitress and menu pic

J. Wilson of Reds Toronto knows that limited menus aren’t always a bad thing. Photo by Iris Amelia, used with permission.

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.

  1. 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.
  2. 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.
  3. 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.)
podium at tech forum

Image not to scale. Not even if you’re reading this on a Cinema Display.

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:

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.



Filed under Manuscript Preparation, Publishing Industry

2 responses to “Notes on ebookcraft and Tech Forum 2015

  1. Thank you for the summary. It occurs to me that one thing I didn’t touch on was how a CMS is scalable and that we push ours just because we’re running a lot of content through it. There’s all sorts of CMS workflow variations (including just adopting CMS best practices in other tools), ours is just one. Keep us posted on your progress!

    • Thanks, Colleen!

      One of the reasons that InDesign gets press-ganged into service as a CMS is that many presses so badly WANT it to be. I like InDesign. I’ve been setting poems on paper ever since PageMaker, then QuarkXPress, then Deneba Canvas, and finally in InDesign. InDesign is magical for paper. I can make it do most things, and Kate & Melissa (both Emerson grads) can make it do anything. To regard our skill sets as sunk costs is to ask a lot of small presses.

      Our current system is terrible…and the worst part is, I don’t even know myself just how terrible it is, because we haven’t yet tried simultaneous publication of a print and a digital edition. We did staggered rollouts for print/digital in 2013, and I spent 2014 digitizing our back catalog and blogging for the Yellow Buick Review. As it stands, we can take a manuscript only up to the point of an RTF file before we fork it into HTML (Dreamweaver) for E-book and InDesign for print. It baffles me that Adobe Bridge isn’t already that CMS, or that InDesign doesn’t seamlessly export to Dreamweaver for E-book creation. Adobe doesn’t need to reinvent the wheel; it just needs a better transmission linking InDesign to Dreamweaver.

      More broadly, having worked at one of the biggest publishers, I know there are huge, institutional frictions to adoption of a company-wide CMS. People who have spent their careers mastering desktop publishing software are going to drag their feet when it comes to adopting a radical workflow. That reluctance is part of what Baldur was trying to overcome with his talk on JavaScript baby steps.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s