First, some background. A print page is generally fairly clean and distraction free. The printed page runs all the way to the edge of the “device” (e.g., the book), like an infinity pool, and everything on the page has been designed by the content publisher, right down to where the page numbers show up and how they look. In contrast, the digital “page” is framed by the bevel of the device it is displayed on and any buttons there, and then often on top of the content itself you’ll get navigational elements and other extras that have been added by the device maker in an effort to improve the digital reading experience, and that are totally outside the content publisher’s ability to design. Every additional thing on or around the screen is a potential obstacle coming between the reader and an understanding of – or immersion in – the information.

My goal with this latest CSS update was to simplify, and eliminate some of the competing visual distractions for the reader. Let the information flow, and let readers “breathe” mentally – give their brains the space to digest the information.

Here’s a visual overview of some of the changes. (Click for a larger view.)

White space is key in accomplishing this simplification; it leads the reader through the information, and creates visual pauses for the reader to take that mental breath. Mark Boulton wrote a really nice article for A List Apart about the importance of white space in web design, and ebooks are no exception.

Unfortunately we still don’t have complete control. Even though EPUB 3 includes full HTML and CSS support in the spec, the different eReading devices offer much more limited support for CSS styles, especially for things like margins, and very few of these devices honor publisher specifications around line heights and character spacing. The reason behind this lack of support is in the reader control offered by the devices: readers can control font size, margins, and other basic aspects of the text, so why let publishers also define those traits within a book? It’s part of the trade off, but we should do our best to make our text beautiful in spite of these limitations, instead of simply throwing our hands up in the air. (I actually did set a line-height on our books, even though in my tests across devices, only the iPad appeared to honor it.)*

In addition to adding whitespace throughout the content, I toned down the borders around the various supplemental elements like sidebars, notes, and images. They’re there but subtle, so there’s still a division, but it’s not glaring or overpowering. I also added a background screen to sidebars, to help keep readers oriented within the book even if the sidebar splits across multiple pages (“The background of this text is gray, so I know I’m still reading something that is set aside from the main text flow.”). I want people to know where they are, and to feel comfortable there.

There are still things that we can’t do anything about (for example, widows and orphans, which to me are especially annoying within section headings), but this is a step forward, and for the majority of our content, these small changes will create a better digital reading experience. The adventure shall continue as eReading device support for styling improves, and as our content moves more towards the multimedia experiences made possible with EPUB 3.

* I feel I should note that I don’t resent this passage of control from publishers to readers – it certainly opens the door to a more comfortable and individualized reading experience, especially for those with poor eyesight, etc. I do think that there’s probably a better balance to be found between supporting beautifully crafted designs and still allowing reader control, and I’m hopeful that we’ll see more progression towards this in the near future.

And I’m not the only one to make this choice. PDF continues to be the most-used eBook format among oreilly.com customers, and we frequently hear complaints from our audience about EPUB and .mobi being “harder to use” than the PDF or printed book. I used to blow these complaints off as just the rumblings of dinosaurs, but I no longer think that’s the case.

It seems to me that PDFs (and print) are easier to use because they’re closest to the intended format for the information. Or more precisely, for the building blocks used to split up the information.

Before we go any further, I want to make an important (and obvious) distinction: Reference books are different from prose. When it comes to reading prose and novels, I’ll opt for a .mobi on my Kindle whenever possible. I could go on and on about how wonderful and perfect my Kindle Keyboard is, how it’s better than print (mostly), and how I wouldn’t want to read any other way.

But tech and reference books come with a new set of rules. As soon as you introduce more than a handful of page elements, and as soon as you really want to try to get people to learn from these elements, the user experience becomes much more delicate.

Let’s rattle off some of the things you might find on the page of a reference book: sidebars, notes and warnings, margin notes, footnotes, images and captions, various levels of headings, and of course plain text paragraphs. All these disparate elements are aimed at helping people learn and categorize information more clearly and in an organized way. These elements were developed in the context of the printed page, and the way they relate to each other has also historically been framed in the context of the static, printed page. Yes, it is possible to port these elements over to the screen, and yes, some of them even translate just fine as-is, but that doesn’t change the fact that they were created for the confines of a static page. Of course they work best there.

Now let’s consider the two most common ways of creating eBooks these days:

• Take the material for the printed book, and push it into the shape of an eBook, without much restructuring at all.
• Make an eBook-only product, but make it back-compatible—ie, make it a PDF as well (since that’s what people seem to want to read), building in the option to print as needed.

But how about we add two more routes to the list:

• Take the material for the printed book and translate it into an eBook, but redefine what the building blocks mean in the context of the screen. (“What is a sidebar? What is a note? What is an index?”)
• Make an eBook-only product with no regard for PDF or print, targeted at the screen and designed accordingly.

In order for ebooks to cease to be a lesser format, to cease to provide a user experience that is inferior to the printed product, they need to be designed for the screen, from the beginning. We’re seeing more and more examples of these kinds of storytelling/learning experiences, built for the screen, using the tools the screen has to offer, and shaking off lingering allegiances to print structure.

An equally viable option, depending on your content, might be to reconsider the way that the elements of the print book are being translated. Just because a sidebar exists in the print book as a box with borders doesn’t mean that’s the best possible representation for it digitally. Or maybe it is, but the important part is that you ask the question, and keep asking as the technology develops.

Educational books and e-textbooks are getting a lot of attention, and I suspect we’ll see more people seriously attacking the puzzle of how to translate them for the screen. This is a perfect time to rethink how we create material for the screen, how we format it, and how people want to read it.

Will there be complications with this kind of publishing? Sure. To start, our popular eBook formats (EPUB and .mobi) and the eReaders built to read them also currently attempt to mirror the print structure, and limit how publishers are “allowed” to format their content. The EPUB 3 standard promises HTML5 support, but the various eReaders have been slow to adopt the new standard, and even when they do, they’ll likely still offer very limited support for just a subset of the spec. This means we’ll need to find platforms both to create and to distribute these new digitally-redefined eBook products. We’ll also need to train production teams to work with these new technologies, and find authors and editors who can think in the context of the screen.

And of course, the business model still hasn’t really been sorted out, which is integrally related to how much resources can be devoted to producing beautiful digital products—but that street goes both ways. Unless we start targeting information at the screen, and architecting that information around elements that work best on screen rather than legacy layout designs meant for printed pages, eBooks will never exit these awkward preteen years where they’re always just second best to print.

Much of the way authors present content is based on what they know is possible with the printed page. But the page has changed—it’s no longer the rigid, rectangular object it once was. It’s important to think about how best to present your content given these new boundaries—one of the key aspects being that these boundaries change. The same reader might look at your content on a large monitor at work, and then switch to her mobile phone on the train home.

Tables are a specific example of content presentation that needs rethinking. Data is often presented tabularly simply because it’s an efficient use of space (and printing pages can be expensive), or because the information is easier to absorb at a glance when presented side-by-side. Unfortunately, large tables are hard to replicate on the digital page. Cutting down the pagecount is irrelevant, and even if the device allows horizontally-scrolling tables or other hacks to fit the content on the screen, the original benefit of having content that is easily absorbed at a glance is lost. (I’m not saying all tables are evil; of course there is true tabular data.)

But what if you included both a tabular and non-tabular display of the same information in your file, and then used media screens to dictate which version to display on which device (or, in an html5 world, on which screen size)? In our table example, imagine that you had a tabular display, like this:

<div class="tabular">
<p>Table 1. Pros and Cons of eBook Formats</p>
<table>
<thead>
<tr>
<td>Mobile format</td>
<td>Pros</td>
<td>Cons</td>
</tr>
</thead>
<tbody>
<tr>
<td>Mobi</td>
<td>Access to Amazon store; mostly cross-platform (with Kindle App)</td>
<td>Limited tag support; disparity among devices/apps</td>
</tr>
<tr>
<td>ePub</td>
<td>Open format; broad formatting support; cross-platform</td>
<td>Different platforms have limited support</td>
</tr>
<tr>
<td>PDF</td>
<td>Print-fidelity; always single-source</td>
<td>Not reflowable</td>
</tr>
</tbody>
</table>

Immediately followed by a non-tabular interpretation:

<div class="nontabular">
<p>Pros and Cons of eBook Formats</p>
<ul>
<li>Mobile format: Mobi</li>
<li>Pros: Access to Amazon store; mostly cross-platform (with Kindle App)</li>
<li>Cons: Limited tag support; disparity among devices/apps</li>
</ul>
<ul>
<li>Mobile format: ePub</li>
<li>Pros: Open format; broad formatting support; cross-platform</li>
<li>Cons: Different platforms have limited support</li>
</ul>
<ul>
<li>Mobile format: PDF</li>
<li>Pros: Print-fidelity; always single-source</li>
<li>Cons: Not reflowable</li>
</ul>
</div>

Both of these presentations exist side-by-side in your text. For the displays where you want the tabular version, you use media queries to set div.nontabular to “display: none;”, and vice verse. The content itself will then adapt to the reading device, presenting the reader with a table where space permits (as dictated by you via media screens), and a linear flow of text when the screen gets too small.

For example, your CSS file might look like this:

@media only screen and (min-device-width: 768px) and (max-device-width: 1024px) { /* Styles for the iPad */
div.tabular {
display: block;
}

div.nontabular {
display: none;
}
}

@media only screen and (max-device-width: 480px) { /* Styles for the iPhone */
div.tabular {
display: none;
}


div.nontabular {
display: block;
}
}

Here are a couple screenshots of the above code in action:

iPad:

iPhone:

Of course, there are technical limitations to this kind of approach right now. For example, these kinds of detailed, screen-size-specific media queries are new to CSS3 and thus are only valid in ePub3, and ePub3 support is still fairly limited across all the different reading devices (there are fewer issues if you’re thinking of streaming html5 books, as browser support for CSS3 is currently somewhat more consistent than in eReader devices). But the point stands that responsive design isn’t limited to just margins and font sizes, but can apply to the content itself. Hopefully this inspires you to think about new ways to present your content, and to make it work across multiple displays.