Building Inkling’s Digital Books

Scaling the authoring, coding, and proofing of Inkling’s digital books required a great deal of experimentation and brainstorming, a process that inspired unique interactions, and pushed the limits of what web browsers could do. Here I describe five tools I built as functional prototypes during this exciting phase, each proving useful enough to be later integrated into Inkling’s official editing product.

Chapter Overview

Inkling books were built using web standards: well-structured, semantic HTML and CSS. Viewing them requires nothing more than a web browser. But early in the development of our authoring and proofing tool—what later became Habitat—we had no way of previewing multiple pages at once, a standard feature of print design applications like InDesign.

To address this deficiency I created a prototype called Chapter Overview, shown above in Figure 1. After selecting a book from a dropdown in the upper left, pages are displayed from left to right using iframes, some tricky CSS, and JavaScript.

This bird’s-eye view enables editors and designers to see the book across an entire chapter. Small design aberrations and misalignments that might otherwise be missed become obvious when seen side-by-side with other examples. And because all book content is built to be responsive the toolbar allowed editors to see the content at varying widths and font sizes as well as at different scales, pulling the eye away from the content to survey the vertical rhythm of the layout.

Focus

A “focus” feature is provided that allows users to select any element—headings, figures, callouts—causing all the instances of that element to be highlighted and the surrounding content muted. In Figure 2 below a h3 is selected. This is accomplished by adding a class to each h3, changing its z-index to be higher than a white overlay obscuring the rest of the page.

Isolating elements can help spot errors: for example, if a heading has been used incorrectly or a class is not used on the correct element. From here the user can also conduct a book-wide search for all instances using a separate tool called Fetch, described below.

The prototype was well received and widely used in the office, but there was still one problem: because figures used in the books are high resolution, image-heavy chapters loaded slowly. Fortunately, when Chapter Overview was built into Habitat a few months later, as shown in Figure 3, an images API was established so that lower resolution images could be swapped in, significantly speeding up loading times.

Fetch: Book as Database

When working with thousands of books it’s critical that the common HTML patterns are flexible enough to handle varying lengths, content types, and responsive layout combinations without breaking. Traditional, linear proofing techniques won’t reliably find small inconsistencies on objects that appear only occasionally. But if we conceive of a book not as a stream but as a database, methods for extracting and reshuffling its content into new proofing patterns are revealed.

I built a working prototype (Figure 4, on the left) of Fetch so that editors could view all the instances of a given element, that appear throughout a book, on one page. Searches were made using standard CSS class chains like section .callout, which would return only those callouts nested in sections, or broader searches, like h2 for all level 2 headings. Because the Table of Contents file is stored as XML it was relatively easy to parse and comb through an entire book.

These results allowed for focused, horizontal proofing and helped unearth typos, design deviations, as well as weakness in the HTML and CSS. It proved useful for authors and designers alike and was rolled in as a primary tool of Habitat.

Pattern Library

Inkling’s early days were filled with discussions about what a book could be. At the time a rumored Apple tablet was about to be unveiled and new possibilities for digital content were just over the horizon. We weren’t yet sure how to reshape complicated, long-form content but we were confident the best course was to use the same standards that gave us the Web. But how can we create reusable components so that books could be built quickly? And how can we keep those components looking great not just on the iPad, but on phones, desktop browsers and future devices?

A big step toward scaling our book production came from understanding the process that large publishers use. In planning the structure of a textbook, editors first categorize the content into recurring buckets—introductions, objectives, summaries, quizzes. This ensures that designers can identify content and apply consistent styling. The subject matter and layout will of course differ from book to book but once you know what to look for these repeated patterns are easy to spot.

This insight lead to our own internal effort at a categorization system mapping content to HTML layouts. Since each publisher used a different system we needed one that not only accounted for their common content categories but also different device layouts and Inkling’s enhancements—video, interactive quizzes, and 3D molecules among others. We called our collection, show above in Figure 5, the Pattern Library and I built and managed roughly 70 blocks of content placeholders, minimally styled for structure yet easily modified to reflect the design of the physical book.

Browser Proofer

When we first starting building books at Inkling our primary target device was the iPad. It was great not having to concern ourselves with cross-browser issues. But as we expanded our reading options to the web we had to make existing content work on desktop browsers including IE 9+, Firefox, and Chrome.

It was not possible to proof each page in each browser with any efficiency. So as a proof of concept I built a script that would parse a book’s table of contents and, using webkit2png, create screenshots at various sizes. It was soon made a formal project, producing a robust back-end that used a screenshot service to pull from the different browsers, and return a JSON file that I used to build a UI.