The physical book is something designers get. It’s got a lot going for it, not the least of which is the fact that it’s physical. The boundaries are there, right before us. No guess work is necessary. And so there are a lot of great examples of well designed books. You needn’t look far to uncover a mountain of beautifully typeset and balanced pages.

Article Continues Below

But what about digital books?

Tablets are in many ways just like physical books—the screen has well defined boundaries and the optimal number of words per line doesn’t suddenly change on the screen. But in other ways, tablets are nothing like physical books—the text can extend in every direction, the type can change size. So how do we reconcile these similarities and differences? Where is the baseline for designers looking to produce beautiful, readable text on a tablet?

This essay looks to address these very questions. This essay also marks the release of an HTML baseline typography library for tablet reading. It’s currently iPad optimized. It’s called Bibliotype and the hope is for it to provide a solid base atop which we can explore. It’s very rudimentary, but rudimentary is a damn fine place to start.

The simple page #section2

Designing a book is largely an exercise in balance: Balance of letterforms and surrounding space in relation to the physicality of a book. In Hochui and Kinross’ Designing Books, they discuss the uniqueness of book symmetry:

The axis of symmetry of the spine is always there; one can certainly work over it, but not deny it. In this respect book typography is essentially different from the typography of single sheets, as in business printing, posters, and so on.

The spine gives book reading a kinetic motion not found in unbound sheets of paper. Forward and backward movement within a book happens because of the spine. And so designers erect scaffolding—text blocks and running heads and other literary accoutrements—around this keystone axis. It is the natural balance point of a spread. The implicitness of this means publishers have largely achieved functional book design right from the beginning: the forty-two line columns of thick type in the Gutenberg bible, even today, are quite a marvel of typographic balance.

If the axis of symmetry for a book is the spine, where is it on an iPad? On one hand, designers can approach tablets as if they were a single sheet of “paper,” letting the physicality of the object define the central axis of symmetry—straight down the middle.

On the other hand, the physicality of these devices doesn’t represent the full potential of content space. The screen becomes a small portal to an infinite content plane, or “infinite canvas,” as so well illustrated by Scott McCloud.

Fig 1. The infinite canvas

Regarding iPad book design, designers are left with a fundamental question they must answer before approaching this device: Do we embrace the physicality of the device—a spineless page with a central axis of symmetry? Or do we embrace the device’s virtual physicality—an invisible spine defined by every edge of the device, signaling the potential of additional content just a swipe away?

Fig 2. Every which way is up

Presently there’s a clear rift in iPad editorial design. There are those applications—iBooks, Kindle, New York Times, Wired, The New Yorker—that attempt to transpose a type of print design built around physical cues to a screen lacking those same cues. They treat the boundaries of the iPad screen like the edges of a printed sheet of paper—sometimes awkwardly forcing content into columns which aren’t optimized for the canvas.

These applications are often characterized by an imposition of arbitrary, non-semantic breaks in content in the name of pagination. Oliver Reichentsien, in his essay iPad: Scroll or Card breaks down use cases for the two models. He provides metrics for determining when to scroll or paginate, and also how the very experience of reading changes between them.

Inconsistent metaphors#section3

Fig 3. The New York Times app: swipe to the left to continue reading this article

Fig 4. The New Yorker app: swipe up to continue reading this article

The inconsistency in which the physical page is mimicked on a tablet leaves readers disoriented, unaware of their position in the context of the greater whole, and unable to easily scan back.

On the other side we have reading applications like Instapaper and Mobile Safari (Mobile Safari being the most fundamental of reading applications on our iDevices) that embrace the boundless nature of the iPad screen. The physical edges don’t bind the text blocks.

Very rarely does one find an application that masterfully merges these two schools. Inkling, however, is one such example of a reading application that straddles the new and old—chunking content in an intuitively predictable and consistent manner within and across chapters, thereby grounding the user via thoughtful navigation. And doing so beautifully, with a confident awareness of the container.

What’s so exciting about all of this is that even now—at the start of 2011!—we’re still refining and iterating on optimal reading solutions to these issues of digital editorial design.

As designers, we need to ask ourselves: Where does our axis of symmetry most rationally lie for the content at hand? From where is the kinetic element of this content born? What’s the rationale behind specific layout and navigation choices for this content and will they be thoughtlessly intuitive to the reader?

We can start with these questions. Then, we can take our content, and—piece by piece—place it back onto this new canvas with considered awareness. These are the first steps to treating the iPad as more than a simple page.

The future and now: books and HTML#section4

In October 2010, I attended the Books in Browsers conference at The Internet Archive. It was a conference with a singular vision: that reading in the “browser” is the future.

I place browser in quotes because, well, browser specific rendering engines are popping up in the darndest of places these days. They can be embedded in iOS apps, eReaders, on desktops, or on mobile or tablet devices. Which is to say: a “book in a browser” does not necessarily imply a book viewed in Internet Explorer (although it most certainly can mean that too).

That conference confirmed what I had long suspected (and had trumpeted privately to anyone who was willing to listen)—that we should be building our books with HTML.

Some of the most popular ebook readers are iBooks and Google Books on the iPad, and the Kindle (both the apps and the device). Google Books and iBooks both use ePub as their format. The Kindle uses an HTML subset to format their books.

An ePub is a zipped package of XHTML files (with some pure XML thrown in for good measure). Others can explain ePub better than I, so I won’t get into specifics here, but the point to take home is that, at its heart, ePub is HTML: the digital book industry is already built atop HTML.

In fact, I had a chance to chat with the iBooks team. iBooks is just a wrapper for WebKit. We’re already doing books in browsers on a high-level commercial scale.

At Books in Browsers, Bill McCoy gave us a first peek at the ePub3 spec: It’s a convergence of HTML5, CSS3, and ePub. Meaning, all the amazing HTML5 and CSS3 based layouts and work we’re doing should, in theory, be available to us within ePub readers in the next few years. (The spec is set to be finished next year but we all know how long implementations can take.)

With WebKit and Mozilla renderers becoming more mature and precise with every release (the latest Mozilla build brings with it discrete ligatures, for example), and with @font-face baked into the ePub3 spec (as a requirement), it’s not hard to imagine ePub3 becoming as robust and nuanced as InDesign for digital book layouts.

With a little more imagination, you can jump one step further: With the inclusion of HTML5, CSS3, and JavaScript in ePub, plus smart rendering engines like WebKit powering our e-readers, iOS and Android style apps for interactive digital books may no longer be necessary. Everything—even the tough interactive stuff—may be possible within the ePub itself. This would have the added benefit of simplifying the current bifurcation of digital book formats (even complex magazines layouts would be possible). It would also help open points of sale: interactive books wouldn’t necessarily have to funnel through an app store.

Regardless of where we see things in a few years, the reality right now is that we (especially those of you reading A List Apart) know how versatile HTML is for layouts. Just look at the nuanced work of Jason Santa Maria and crew on their Lost Worlds project. It’s a testament to the capabilities of browser-based layouts.

It’s also worth noting that there is now a generation of designer for whom working with HTML and CSS is more intuitive and quicker for design iterations than using specialized software like InDesign. This is the generation of designers that will be most capable of bringing the best of print aesthetics to the web with nuance, balance, and mastery of implementation.

Fig 5. Tablet typography. A long form reading HTML library.

Bibliotype: a template#section5

We need a starting point. We know HTML is the future so why not build a core design template for long form tablet reading? With this in mind, I set out to build just that. The end result is called Bibliotype. It’s a simple set of CSS, HTML, and JS files that provide a base for anyone looking to bring long form reading to tablets (be it in a CMS, blog, iOS app—anything using WebKit as a renderer).

I worked with the wonderful folks at Enhanced Editions in the summer of 2010, helping them design and think about long-form reading on the iPad. I’ve also had the humble pleasure of working with the iPad publisher (and I do see them as a publisher, albeit a new kind of publisher), Flipboard, since the fall of 2010. This template and some of the ideas I’m presenting here are a product of the thinking and design work born from those collaborations. Bibliotype wouldn’t exist without their support and the opportunity to work together.

Point your iPads (or browsers) here for a demo.

The most important point to consider in tablet editorial design is that tablets are some of the first digital screens to be engaged at a variety of distances. Until now, a desktop screen was always a few feet away from one’s face. Or, with smart phones, at arms length. No longer with tablets.

I break tablet reading distances into three main categories—Bed, Knee, and Breakfast—and define the categories by generic use case:

Bed (Close to face): Reading a novel on your stomach, lying in bed with the iPad propped up on a pillow.

Knee (Medium distance from face): Sitting on the couch or perhaps the Eurostar on your way to Paris, the iPad on your knee, catching up on Instapaper.

Breakfast (Far from face): The iPad, propped up by the Apple case at a comfortable angle, behind your breakfast coffee and bagel, allowing for handsfree news reading as you wipe cream cheese from the corner of your mouth.

So: distances near, medium, and far.

I believe all serious tablet reading software should typographically account for these three use cases. Accordingly, I’ve built Bibliotype to do just that.

Fig 6. Bed, Knee, and Breakfast in portrait mode

(An aside: when I showed this to one friend, his first interpretation was Bed, Knee, and Breakfast as definitions for types of content. The content you read in bed isn’t the same content you read on your knee or over breakfast. Very true.)

Furthermore, these three use cases need to be treated differently depending on orientation. This means we have to define six typographic styles: margins, line lengths, and line-heights do not seamlessly transpose from one orientation to the other.

Our final base template has the following qualities:

CSS media queries to detect device orientation,

rules for both serif and sans-serif fonts (using Georgia and Helvetica),

hyphenation via Hyphenation.js,

font-size, line-height, margins (and, implicitly, line-length) defined for three tablet reading categories in both orientations,

ability to toggle both ragged right and justified text,

Settings for low and high contrast backgrounds, and

turning on and off a grid to see body and title block placement

footnote styles

The Structure#section6

These templates are based off the most fundamental approaches to the iPad canvas. We define the axis down the middle of the screen and build our text blocks as centered with even margins to the sides. Even though these templates are basic, they should shave hours of first-movement pain from further explorations and experiments.

The content components are:

running head

title block

intro paragraph

chapter text (composed of several paragraphs)

final paragraph

fleuron

footnotes

running footer

The underlying goal as designer is to achieve comfortable readability in all sizes for each orientation. I started with what felt like the most agreeable font size for each reading category. I then set the line-length for that text size at whatever length allowed for approximately 12-15 words per line. With font size and line-length defined, I built up the leading until the text blocks felt comfortably whole.

The basic compositional goal is to “hang” our text blocks within the frame of the iPad. As with many things design, this is an exercise in the balance of mathematical proportions and gut intuition. Depending on the font-size, some title-blocks want to sit higher or lower in the frame. I like to imagine the title block as being the nail onto which you hook a string holding up the body text.

To help find the right spot into which this nail should be driven, I created simple grids for the two orientations. This lets us quickly see where elements are falling within the canvas’ mathematical balance points.

Fig 7. In landscape mode with the grid turned on

The template provided here is also meant to be a quick environment for debugging long form tablet typography. You can test hyphenation, assess grid position, play with typographic variables, and see those results quickly as you edit the HTML.

Fig 8. In landscape mode with the menu invoked

This is all very simple. Book design isn’t a black art—like many things it’s a matter of deliberately considering micro-nuance in the context of a greater whole. We add each piece slowly and thoughtfully, punctuating decisions with coffee breaks, whiskey, and neighborhood walks.

The iteration of Bibliotype released with this article is by no means hyper-exhaustive, but it is a fine start. I can read that chapter of Flatland at those three sizes, in those three states (bed, knee, and breakfast) more comfortably than I can with most other available iPad eReading software. Yes, the bar really is that low!

We are, of course, ignoring the whole “card” vs. “scroll” debate. Whether content scrolls (like traditional web pages) or treats the canvas of the iPad like a well-defined sheet—breaking the content into swipeable cards—is both a technical and editorial matter. The margins, line lengths, font sizes, running headers, and footers don’t change (much) between cards or scrolling. They are defined by horizontal space. And horizontal space stays the same in either context.

Using the templates#section7

Bibliotype is released under the MIT License. So nobody owns it. Meaning, you can use it as a base for anything—commercial or free—that you want to build. The only stipulation being that if you build off of it, keep the copyright notice (http://craigmod.com) in your application or book’s copyright/about page.

Bibliotype is hosted on github. You can grab a copy here:

https://github.com/cmod/bibliotype

There are an endless number of use cases and devices for which Bibliotype can be adopted and I’m happy to open it up for the community to extend and build upon together. (For example: pagination via Joseph Pearson’s great Monocle ePub Javascript library might be a fun project with which to mash Bibliotype’s styles.)

If you’re testing new fonts—looking for the right balance of size, leading, and margins—I might suggest turning on two JavaScript functions which are commented-out by default: swipe right to reload the page, and swipe left to show the grid.

On a desktop we have tools like Firebug that allow rapid visualization of changes to CSS and HTML. On the iPad, however, it’s a little more tedious to repeatedly hit reload, or, in the case of a chromeless instantiation of Safari, exit the app and re-open it. By enabling swipe right for reload and swipe left for grid, the debug process becomes infinitely simpler, quicker and may just save you from losing your mind.

Still looking#section8

iPad reading typography is defined by two things: The visible portion of the canvas (is it occluded by any images, columns, menus, or chrome?), and the way someone is reading (bed, knee, or breakfast?). The canvas can be thought of as extending in any number of directions, as having any number of axes, but we’ll forever be bound by what the reader can see, and that space defines how—on the most basic level—to format the text for a comfortable reading experience.

Take Bibliotype and play. Transpose the axes of symmetry, shift text blocks around, paginate, imagine content extending in all directions with small visual cues to guide the reader. How will the typography keep up with these scenarios? What modifications will a base like Bibliotype require as we explore this space? And most importantly, what feels most natural, most effortless for the reader?

I look forward to seeing where we go from here. Knowing wherever it is, the text will be comfortable to read, and that HTML is at the heart of it all.