a frontend designer

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?

Two examples of book content built on top of our HTML patterns.

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.

On the left, the Pattern Library with entires along the left side nav and information about each pattern in the main content area. In this case a blockquote. On the right, an example of that same blockquote in real content with added styling.

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 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. See Figure 2.

Another tool that aided this process was moving from CSS to Sass. Maintaining the ever-growing list of patterns in a single, ballooning CSS file became unsustainable and Sass provided the escape hatch we needed. Our first step was to divide up the code into discrete chunks over multiple files. Patterns were now self-contained, facilitating collaboration among developers, and better organized. Secondly, using the programmatic features of Sass we were able to DRY out our code, replacing repeated hard-coded values with variables and shortening lengthy blocks with mixins.