What follows are two hierarchies of e-book design, outlines that climb from the trivial and decorative to the integral and necessary.

The visual design examples are books that I happen to have on my desk. The interactive design examples are, for the most part, major titles from interactive media history.

1. All meaning is in the text. A good default stylesheet is preferred over having to design and test a custom one. (Most novels.)

2. Type and cadence has meaning and connotations that a default stylesheet can't convey. ( Bringhurst's The Elements of Typographic Style .)

3. Strong and distinctive aesthetics are a part of the message. (Twyla Tharp's The Creative Habit . Constance Hale's Sin and Syntax .)

4. Design as UI, essential to the reading, but doesn't require a complex layout. (Most computer/programming books. Jesse James Garrett's The Elements of User Experience .)

5. Design is dense with meaning, fancy layout needs. (Tufte's books. David Pye's The Nature and Art of Workmanship . Josef Müller-Brockmann's Grid systems in graphic design .)

E-reader platforms serve the first type of e-book very well and, since most designers who think they're working on type 2 books are actually working on type 1 books, they serve type 2 books very well as well.

(Bringhurst's book was the only book I found on my desk where the typographic style was, appropriately, an integral part of the book's meaning. I'm sure there are others, but they aren't common. In any case, the web platform isn't capable of delivering the typographic nuance necessary for type 2 designs. Not until the spec for CSS font-feature-settings settles and is more broadly implemented.)

Type 3 books are largely let down by e-reader platforms as all of them require the ability to adjust margins and set backgrounds properly, something that all major e-reader platforms prohibit, even iBooks and Kindle Fire.

Type 4 and 5 books are possible to a degree in Apple's .ibook format, but even those are partially let down by its inability to use embedded fonts. (Just try and open one up to embed fonts. Crasherama.) Those books would also, unfortunately, only work on iPads.

Some of these books (types 3, 4, and 5) are available on the Kindle platform but have had their personality and style completely removed in their e-book versions. Charging anything at all for these mutilated remains is too much. That publishers pretend that these editions are in any way equivalent to their printed versions borders on criminal fraud.

Even worse: There is no way for readers to discover which is which when they browse e-bookstores. They aren't given the tools to tell the books that have been mutilated in their e-book transition from those that haven't.

Fixed layout e-books, as implemented by Apple and Amazon, don't solve any of these design problems as they are all pre-paginated. These books are text-heavy. Doing them in fixed-layouts would be insane. It would prevent text from reflowing when resized (where resizing is even possible) and involve a massive amount of work to create a sub-par book.

IDPF's Fixed Layout spec would solve most of these problems because it adds several important capabilities that Amazon's and Apple's implementations lack:

You can mix pre-paginated fixed layout chapters with reflowable chapters. This lets you drop into a fixed layout for sections with complex requirements.
You can create adaptive 'fixed' layout chapters, ones that don't define a fixed viewport but use media queries to adapt the design to the e-reader.
You can use overflow: scroll to create chapters that scroll like web-pages.

These three capabilities mean that IDPF's Fixed Layout specification is actually useful to regular books, not just illustrated books. It would let a regular text-oriented e-book have a beautiful title page and elegant section divisions using fixed layout pages, something that many designers have been struggling with during the entirety of the e-book transition so far.

Incompatible file formats reduce innovation and harm the e-book market. The time that e-book designers spend implementing several versions of their e-books is time that isn't spent on finessing the design and implementing new, innovative, features.

Fully supporting the IDPF Fixed Layout spec and letting designers both adjust page margins and set full-bleed backgrounds would cover more than 90% of the publishing industry's visual design needs.

I've been looking into how e-readers handle backgrounds set on the HTML or BODY elements of an xhtml file. After trying my test files in several readers I can only come to two conclusions.

The e-readers' overrides result in a non-standard mess that is both ugly and can result in the body text becoming invisible. Neither does the reader any favors.
There is no consistency from e-reader to e-reader on how they override margins and HTML/BODY backgrounds.

When I first started investigating how e-readers implement page margins and backgrounds I was under the impression that their overrides caused them to, essentially, set the HTML element's background-clip property to 'content-box'.

My guess now is that their implementation is based on an interpretation of CSS 2.1's section on paged media where the content is clipped by the page's margins. E-reader vendors seem to take this as an indication that backgrounds in on-screen paginated contexts should be clipped to the page's margins as well.

That is, I'd argue, a misinterpretation. CSS 2.1's paged media section is discussing printed media, where almost no printer shipped to consumers can print full-bleed backgrounds. The spec as defined is merely putting order to a real-world limitation that cannot be removed.

This limitation does not apply to on-screen paginated contexts and so in my view the only correct thing would be to render the backgrounds set on the HTML element edge-to-edge, i.e. full-bleed. Maintaining consistency with default screen rendering behavior should trump the print media edge case.

Allowing authors to set the page's margins using @page and a full-bleed background using the html selector would solve a lot of design problems e-book developers are facing.

True to the non-linear nature of interactivity, this isn't a true hierarchy. More of a bag of interrelated goodies that you can mix and match. Nevertheless, they are listed in the order of increasing impact.

2. Decorative. Added video or 3D models where illustrations would do. Links used as simple references. (Most 'enhanced' e-books.)

4. Structural. Interactivity is integrated into the book's structure. (Books with extensive cross-references. If Monks had Macs . Afternoon . Patchwork Girl . Solar System . Skulls . The Elements . The Wasteland .)

5. Networked. Outside meaning enters into the book, surrounds and frames parts of it. (Kindle notes and popular highlights.)

Most attempts at e-book interactivity over the last few years have been decorative . Add a few videos and gloss to an established text, raise the price, and hope nobody notices that it's a lazy ripoff. Most of the e-reader platforms allow for this kind of interactivity, at least to a limited extent.

With Apple's announcement of the .ibooks format we've begun to see renewed interest in functional interactivity , where widgets add substantially to the meaning and important parts of the text are delivered through interactivity.

Most developers misunderstand networked interactivity . They almost always take it to mean that data can be pulled into the book and the book changed in some suitable way.

Most of the time this means data that's pulled from or pushed into the network, but that's not a requirement of the basic concept.

These types of interactivity are easily implemented on the web with standard tech but the situation in e-books isn't nearly that simple, for a variety of reasons:

Most e-book platforms don't offer javascript or only offer a non-standard selection of javascript APIs (like iBooks).
App platforms have a larger mindshare and offer a much larger, more unified, user base. They also offer developer documentation and extensive tools , something that the e-book world doesn't offer at all.
Most javascript touch APIs are non-standard and many are patent-encumbered . It is almost impossible to implement non-proprietary interactivity that builds on the tablet experience.
Most of the attempts at rich interactivity in e-books so far have been proprietary extensions (flash embeds in Adobe Reader and Apple's .ibooks format).

The complete absence of developer documentation or tools in the e-book field is a large part of what makes app- or web-based interactive books so attractive to publishers. Add to that the iPad's large, relatively uniform, and paying user base and you begin to see why so many 'enhanced e-book' efforts begin and end with native iPad apps.

(This ties in with my earlier theme : e-book platforms are competing with other platforms, both for talent and for customers. A publisher's biggest enemy isn't Amazon but Angry Birds.)

Adding capabilities hasn't really resulted in much. A bunch of titles appear that include video or Fancy New Widget™ but most of them are either unpolished or badly thought out. None of them play a major role in the sales charts.

What else do you expect when we are given poor documentation and no tools ? What else do you expect when you can't even trust basic CSS formatting to be preserved across all of the major platforms?

Time that is wasted working blind, testing across half a dozen platforms with no tools to help you, and reimplementing the same fixed layout again and again, is time that doesn't go into product development, doesn't go into polishing the book, doesn't go into play-testing widgets, and doesn't go into turning a half-baked design into something fantastic that will blow the reader's mind.

Polish, however, is a great way to differentiate, to rise above the rest. If your implementation is the best, that's a differentiator. Having the capability in the first place is a differentiator—“X now supports videos in e-books!” But incompatible capabilities aren't, because they won't get used .

All of the major platforms, Kindle, Kobo, Nook, and iBooks, can trust that—no matter how market share is distributed among them—publishers and e-book developers will test and try to make sure their books work on all four.

In fact, that's kind of the problem. Unless a capability is compatible across all of the major platforms that implement it, that capability will never see widespread and profitable use, because developer will either target a compatible subset of the feature, or they will do a simple design that is easy to port.

So, a plea: when you add a capability to your platform, either make it compatible with existing capabilities on other platforms, base it on an existing standard, or make sure it can degrade gracefully. Then write some documentation. Then make some nice tools.

(That is, don't do what Apple did with .ibooks, and do a wholesale, incompatible, fork of a standard format. Extend the standard format in ways that tie into the built-in fallback capabilities.)

Do this wrong and you'll end up with a bunch of badly thought out titles languishing unsold on your servers. Do this right and you might end up enabling e-book genres that grow the e-book market by appealing to non-readers or satisfy needs readers didn't know they had.

One area where e-reader vendors have free reign in their attempts at interactivity is when it comes to implementing new features for their platforms.

Kobo has been doing this in its effort to integrate face-book and gameification doohickeys, although I can't really test it because I don't use face-book and enjoy gameified UIs about as much as I would having my toenails chewed off by a badger.

Which isn't a bad thing, per se, for Kobo. For every person like me, who hates the direction they've gone into, there's going to be at least one other person who thinks it's exactly what they've been looking for, the most brilliant thing since Spice Girls.

Amazon has been going in this direction as well, albeit in much less intrusive and more usable way (at least for me, see what I said above about polarized opinions). Popular highlights, for example, is a clever use of network data, re-contextualized into the book for the curious.

More interesting to me are the Public Notes , which are live, networked, footnotes. Imagine being able to issue a correction to a book and have it appear as a footnote in all copies of the book, automatically.

I think that all books should have the Public Notes by its author enabled by default and I think that they should let authors use HTML in their public notes. They don't need much HTML support: bold, italic, links, and maybe images. Send a plaintext version to legacy devices and the fancy HTML notes to newer ones. Then give authors a nice web-based GUI for creating and updating their notes.

These suggestions and these tactics don't apply to just Kobo and Kindle. Reading software has a long history of experimentation, starting with some of the early hypertext systems and continuing into the Multimedia CD-ROM era and that's before you even get into the possibilities the internet offers.

The problem with generalizing about publishers is that you can't generalize about publishers. Big or small, they are all uniquely crazy.

I'm not going to go into specific implementation tactics. The options at the moment are very limited. You can do simple audio and video on most e-reader platforms but for anything more than that you either need to go proprietary (.ibooks), online (a website) or native (iOS or Android app).

Ignoring the technical side (yeah, I know, that's ignoring a lot ) the problem with interactivity can be broadly broken down into three areas:

Given that most publishers are built around making books, it's understandable that their first attempts at interactivity involve extending those books, to promote them, add value, extend their shelf-life, etc..

Most of the material would add more value on the web. There is a considerable opportunity cost to locking a good author video inside a book when it could be on the web, promoting the book and increasing its sales.
The books weren't written with interactivity in mind and so don't benefit.
The mode switch from text to video, interactive maps, widgets, whatever is too disruptive because the writing style is too immersive. Multimodal interactivity requires compromises in all of the forms that are to be integrated. You can't do full narrative videos. You can't do detailed radio-style productions. You can't do involved, deeply immersive, prose. You need to write differently and edit differently.
It adds no value to the book. Seriously, why are you doing this? People want the damn story, not a grab-bag of your marketing materials bundled with their fantasy yarns.

Publishers who are focused on text-oriented books are better off spending their interactive efforts on making their websites interesting.

The exception are, of course, illustrated books. The writing style and materials are more suited to multimedia and in some cases additional interactivity lets the original breathe, gives it the space it needs to do its concepts justice.

The publishers whose backlists are full of these titles know this already and are way ahead of pundits like me. They have been quietly making the most of their titles, with none of the fanfare or massive expense that follows the more high-profile efforts by big publishers.

The world isn't limited to books. A lot of companies own the rights to large libraries of film, video, audio, and short form text. Building original works with existing stuff is a lot easier than shooting, recording, and writing everything from scratch, and you have a lot more freedom to mess around and adapt everything to work in an interactive context.

You still need developer talent and you can't just recruit anybody. Building entertainment software requires a different skill- and mindset from that of building an e-commerce website. People that do entertainment-oriented interactive media are few and far between and usually get to work in environments that are considerably less frustrating than today's e-reader platforms.

Which is why you end up seeing a lot of native apps or websites and very few interactive e-books proper. The talent goes where the tools are.

The alternative is to train your own people. Then you let your staff pad their CVs with a couple of your own titles before they head off into other fields. Fields that give their developers actual tools to accomplish their goals and documentation on how to get there.

The problem with creating original interactive works from scratch is exactly the same as with problem 2, multiplied by ten. You need talent. You need writers who understand interactivity, hypertext, and feedback loops. You need developers who think in terms of game-like mechanics and play-testing. You need people and you need them skilled and with experience.

There aren't that many of them around, so they're relatively easy to find. They are also, for the most part, gainfully employed.

The biggest problem here is that nobody really knows how to pull this off. Games come the closest, but there's no science there that can solve our problems. This is an art, pure and simple, and an immature one at that.

With good developer tools and documentation, it'll take years of experimentation before original interactive e-books become an industry of their own.

Let's be honest here. As readers, we never asked for interactivity in our books, and the interactivity we need we won't get, because both e-reader vendors and publishers view us as cattle to be herded, locked up, and milked until we die.

Publishers' attitudes towards readers are roughly analogous to that of a tax collector to a tax payer. It has escaped them that they aren't as inevitable as death or taxes—that they operate in a free market, competing with other forms of entertainment and other, more easy-going, publishers.

E-reader vendors, on the other hand, operate under the assumption that competition is constant, never-ending, brutal, and ruthless, and will apply whatever method they can think of to grab and maintain advantage.

They may not state it plainly but it's clear from their behavior that features that could even remotely diminish platform lock-in aren't likely to be implemented.

Which is a pity, because most of the features that readers need are features that might be seen to compromise lock-in. They would all increase platform loyalty but decrease lock-in.

For example, the single most valuable—productivity boosting—feature that an e-reader platform could add would be a complete and open API for bookmarks, highlights, and notes.

If I could have all of my highlights and notes automatically sync—marked up and tagged—to my Simplenote account, that would trump any design feature or widget e-reader vendors can possibly think of.

Reading is a big part of the writing process, always has been . It's been the one part of writing that computers haven't helped improve so far. E-reader platforms have the chance to make history by integrating their reading tools with existing writing tools

Imagine all of your Kobo notes and highlights syncing to Simplenote and from there, as if by magic, into Notational Velocity , Scrivener , or Tinderbox .

Imagine all of your iBooks data, your scribbles, bookmarks, highlights, available through a simple API call to all of your iOS writing apps. (Only with permission, of course.)

While all of these amazing applications have revolutionized the art and craft of writing, their reach is limited to what we can put into them. The one transformative feature that e-reader platforms can add that isn't reliant on developers, publishers, or file formats, is open access to reader's annotations (highlights and notes).

Hierarchies Of E-Book Design

table of contents

Introduction

Visual Design

Full-Bleed Backgrounds And Margins

Interactive Design

E-Reader Vendors

Capabilities

Features

Publishers

Extending Existing Titles

Re-Appropriating Existing Material

Original Works

Readers

Links

the end