A few weeks ago, I surprised myself. I had decided to learn a new code language, and O’Reilly of course has a great little book about this particular language, so I pulled up the eBook files, and almost without thinking, I loaded the PDF onto my iPad, rather than the EPUB. And my brow furrowed as I tried to figure out why I had made that choice, because as an eBook developer—as a CSS and web technology devotee—shouldn’t I also be a devoted EPUB user?
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.