ENTRIES TAGGED "Readium"

In an article posted a few days ago I shared the first part of an email exchange between Bill McCoy of the IDPF and Sanders Kleinfeld of O’Reilly. They were debating the merits of HTML5 and EPUB 3. In the second of this three-part series they dig deeper into the capabilities of EPUB 3 and what the future of this format might look like:

Why isn’t EPUB 3 leading to more innovative products?

Bill: It seems to me that your argument amounts to (to paraphrase): “EPUB 2 is good enough for plain text, everything else can and should be a web app, so let’s not bother with EPUB 3”. That’s not an entirely new argument, but I’m a bit surprised to hear it from you.

Sanders: I definitely did imply this, and I really wish I hadn’t, because at its heart, EPUB 3 *is a web app*; it’s just packaged according to a specific standard. I have absolutely no qualms about the feature set EPUB 3 was designed to support, and I think those features are exactly what is needed to do Category 2 digital content.

My complaint is that there’s really no sane way to do full-fledged Category 2 [more sophisticated, feature-rich] emedia *right now* in EPUB 3 given today’s landscape of ereaders and the features they support. But that’s really a knock against the tablet vendors, not EPUB 3, as I feel they’re the ones stifling innovation.

Anyway, if you are a publisher who wants to press forward today, you really have to pursue an app, in the sense of something that can either be served via a Web browser or compiled and distributed in an app store. I don’t really feel I can advocate that publishers do an EPUB 3 at this time, unless they’re content with limiting its marketability largely to the iPad, and even then, Apple does not make it especially easy to do a standard EPUB 3 for iBooks (because presumably they’d much rather you use iBooks Author).

But I do regret sounding so dismissive of EPUB 3 in my remarks. I also wish I had specifically mentioned Readium as an example of an app that holds a lot of promise in terms of furthering the goals of an open HTML5-based pathway for modern “ebook” content. I hope it helps crack the stranglehold that tablet vendors have over feature support.

Bill: [My first issue with what you noted earlier is that] publishers can’t afford to create custom web apps for each title at scale. A declarative content model and associated toolset will be required. Unless we want that model and toolset to be closed and proprietary, EPUB 3 or something very much like it will be needed.

As you know, creating compelling engaging web apps isn’t easy.  Most publishers don’t have O’Reilly’s technical talent and resources and I doubt even O’Reilly has enough JavaScript software developers to make web apps for every title. There’s a reason there’s only one Financial Times and a reason there’s only one Principles of Biology, and that’s in large part that they are extremely expensive endeavors.  At Google I/O the Chrome team spent a lot of time talking about how offline in the browser didn’t deliver a great user experience for things like Google Reader, and that’s why they are rolling out new packaged apps.

Publishers will demand tooling and that tooling will require underlying content representation that’s not just JavaScript, and will largely be assembling and configuring widgets, not writing them and the apps around them from scratch. HTML5-based tools like Habitat and iBooks Author have underlying representations but they are entirely closed and proprietary. And, I don’t think you are implicitly arguing that either of these toolsets is the path forward rather than a free and open content representation that enables multiple tools from different vendors as well as multiple distribution options.

Sanders: Agree with all your points above, and heck no, I am definitely not arguing for iBooks Author or Habitat over EPUB 3 🙂

Open source development will lead to additional EPUB 3 growth

Bill: If you get to the more micro level of features, EPUB 3’s “extra layer” (as you called it) has features like Media Overlays and declarative triggers. Do you really think that publishers who need to synch audio with text or wire up buttons to media controls should have to hand-code home-grown solutions every time they need to do it? How about other accessibility features?

Sanders: Excellent points. I agree, and I do not think I gave credit where it was due here to the packaging layer of EPUB 3. However, much of the hard work of creating an interactive web app exists whether or not it’s packaged in EPUB 3 format or not. Composing interactive games in <canvas> is basically the same challenge either way. I think that in the future, ebook publishing is going to look a lot more like software development than print production, so if content producers want to stay competitive, I think they will need to hire more software engineers.

I do think, though, that just as there’s been a huge wave of open source innovation that’s sprouted in the past several years around doing web apps for mobile and tablet devices (I’m thinking of software like jQuery Mobile and bootstrap.js), there will be a similar wave of development around tools and widgets facilitating the creation of interactive ebook content. It seems likely that this will facilitate and complement the growth of EPUB 3, which is great. The bummer right now is that EPUB 3 feels like more of a hindrance than a help, because I can’t get it to render the way I want in Nook Tablet’s ereader, but I can just unzip that same EPUB file and put it up as a web site, and come much closer to the results I want.

Bill: [My second issue with your earlier points is that] EPUB 2 isn’t good enough even for text-centric non-enhanced content. 

For one thing we have fixed layout. For another, vertical writing and other global language features: even for a novel, EPUB 2 isn’t enough in Japan. Thirdly, accessibility.  These are all defined in terms of modern HTML5/CSS features that aren’t part of EPUB 2. Fourthly, we have a much tighter spec for content and reading system conformance in EPUB 3 than in EPUB 2. So even if we accepted the proposition that publishers should create web apps to deliver highly interactive content, there’s enough reason to move non-interactive content to EPUB 3 to get these other benefits.

Sanders: Yes, I agree with this point. In retrospect I feel I was wrong to suggest that EPUB 2.1 was good enough as is for text-centric content. I do see the need for broader accessibility and foreign-language support.

Sanders makes a great point about EPUB 3 not being fully supported in most ereader apps. I’d like to think once that happens we’ll see much more innovation and less of a need for publishers to create platform-specific apps. I’m skeptical though. Ours tends to be an industry of followers where we wait for others to take the risk, prove the investment worthy and then jump in. I figure it will be the small, lean startups that will do more exciting things with EPUB 3 and the rest of the industry will follow. What’s your opinion?

Here’s the link to the third and final portion of this series.