Coding in Paradise

About Brad Neuberg

The Three Things that Can Transform eBook Development

Developing next generation eBooks that have complex non-narrative content is like web-development was in 2001. You are dealing with a sea of balkanized reading platforms, many of which have buggy implementations of web standards, little documentation, and make it difficult to even do simple things well (exceptions).

I know I'm biased, but I do believe Inkling is one of the exceptions to this, in the sense of trying to create a real next generation reading system that can handle complex content beautifully. I do have to say that I think iBooks also counts as a modern reading platform when it comes to eBook development.

Designing eBooks in this world is a frustrating exercise. How can we move the needle and improve the state of the art across many of these reading systems so that eBook development becomes not a struggle and a pain but a joy and a pleasure?

Image by martinak15

I think a strategy of three key things could help to drastically change eBook production in the eReading world: Document, Score, and Shame/Success.

#1: Document

The first necessary step is to get great documentation. Folks like Derek Schulze, Liz Castro, and everyone working on the BISG support grid, have been doing the hard work of shining the light into the dark corners of these different reading systems. We need something like the Mozilla Development Network (MDN) giving deep technical documentation of support and bugs.

For example, for any given reading system, does it support JavaScript? Does it support cookies? How about MathML? Does it support SVG? What features of CSS does it support? What actual tags from HTML5 does it support? Does it support any of the HTML5 local storage features? What are the full list of bugs around each of these?

We need this kind of deep knowledge. The broad desktop and mobile web have this kind of information and it has transformed development. Sites like MDN and caniuse.com; PPK's effort to exhaustively document support for different APIs; and toolkits like Modernizr, which mix in support information onto a page to adaptively change the experience based on a platform’s features.

This is the first leg of the battle cry. We need exhaustive, deep, and wide ranging documentation for the eReading systems that are out there: the Kindle's many devices and versions, Inkling, Nook, iBooks, and so on.

#2: Score

This is the second major step. All of the EPUB3 specs, including the fact that they ask for support for HTML5, MathML, and SVG, need to have a suite of conformance tests that check for actual compatibility on real reading systems.

The most important thing, though, is this: these tests need to spit out a single, clear number, from zero to one-hundred percent that gives details on support. This is what the Acid tests did on the web, and it drastically changed browsers. Acid tested support for HTML, JavaScript, CSS, bits of standards like SVG, and so on, and it spit out a single number. This single number became a rallying cry and a clear level of support for essential web technologies that people could understand.

People can‘t understand a giant support matrix to glean and understand overall support; they can understand a single number. It’s a report card: do you have an A, a B, or are you failing with an F? We need to spit out a single number and consumerize that number. This happened with desktop web browsers; Internet Explorer 7, for example, got less then 20% on the Acid tests, then Firefox, Safari, and Chrome came along and had even better scores on the Acid tests. Major magazines and review sites picked up on this number and score card and turned it into something that normal web users asked for and understood. It created a clear metric for competition, just like the Miles Per Gallon (MPG) standard for cars did, in order for consumers to understand something that might have appeared esoteric and complicated until it was boiled into a number.

We've got to get a suite of conformance tests that spits out a single number.

What about simple versus sophisticated reading systems with voluntary parts of the EPUB3 spec?

#3: Shame/Success

Once we have documentation, and once we have a score, we have to use the power of shame. This is what the WaSP group (Web Standards Project) did for web development in the early 2000s. They banged the drum, shaming those whose documentation and scores obviously showed problems, and giving the love to those whose documentation and scores were obviously showing successes. In the eBook world we've got to give shame and success, call out shame when it should be called out, and call out successes when people are doing a great job in moving the needle forward, using the scores and documentation above as our guide.

I think these three tools can transform the way we approach eBook development and bring it up to the level that we have on the web. The web was at a similar dark level in the early 2000s, highly balkanized with one browser, Internet Explorer, commanding the roost. Internet Explorer had stopped developing for years and kept the web from evolving. Today the contemporary web is flourishing from a development stand point and has come a long way from those dark days. I would point to the use of these three tools as one aspect that helped move things forward; let's apply these same tools to the eBook world.

Subscribe to my RSS feed and follow me on Twitter to stay up to date on new posts.

Please note that this is my personal blog — the views expressed on these pages are mine alone and not those of my employer.

Back to Codinginparadise.org