• Print

EPUB 3 facts and forecasts

Why ebook publishing will look more like software development than print production

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.

tags: , , , , , , , , , , ,

Comments: 5

  1. Well, you both summed up my feelings about EPUB3. I’m a designer/developer, I work in a publishing company and I’m in charge of “digital publishing”. I’ve been working with EPUB for 3 years now. Developing for EPUB is *very* frustrating. When I see what I can do when I work with iBooks Author, Digital Publishing suite, HTML5, Hype or Mag+ and what the “possibilities” are with EPUB right now, I feel cheated.

    As you know, with EPUB, you have very limited control on the typography and layout. Printed books and printed magazines are superior on that level. On the other hand, EPUB can’t be used for interactive and dynamic content. The web and apps are superior on that level.

    Right now, EPUB is the worst of two worlds : It’s static like a printed book and it’s cold like an electronic device. It could be the best of these two worlds : beautiful like a printed book and dynamic like a web site. The only thing that EPUB has that the other platforms don’t really have is reflowable content. Woohoo. And the reader can change the size of the characters and the font, a feature that invalidates the graphic designer’s work anyway.

    The reality, now, is this : When we meet clients and authors interested in publishing digitally, we show them all the options and most of the time, when they see what an EPUB looks like,they react with disgust. And then they choose to publish a PDF(!), even after we tell them the limitations regarding distribution and reflowable content.

    E-Ink readers look like old gameboys. Working with the EPUB format is difficult and frustrating. It shouldn’t be.

    I could go on but you see my point.

    – PS : English is not my first language so sorry if the grammar is not perfect. –

    • In some ways, I think the opposite: many self-published authors are lucky to be publishing right now, when the difference between what the big companies and what a determined amateur can create for, say, the Kindle is so small:


      Sums up that point of view.

      Granted, things are very different for stuff like textbooks, where the status quo isn’t really good enough, but I do worry that authors will worry about “chasing tail lights” in terms of whiz-bang technology instead of worrying more about marketing and cranking out good content.

      • You’re right. I should have specified that I work in the textbook industry. On one hand, I love the fact that individual authors can now publish in a DIY fashion (with mixed results) and I’m sure some gems and some original talents will be found because this is possible.

        On the other hand, for books and magazines that are not “just text”, epub is not good enough. Textbooks, for example, need a lot of graphics (figures, tables, maps, etc.) and epubs just don’t do the trick regarding that kind of ressources. Navigating through the epub is an issue too, for students.

    • I can’t disagree with your POV on the reality now in the broadest sense, but I think you are talking about EPUB 2 not EPUB 3 which is based on HTML5 so will have the full capability of handling interactive and dynamic content. Of course EPUB 3 implementations are not 100% complete yet but iBooks, Kobo, and VitalSource for example are already supporting quite a lot of it including JavaScript and rich media (audio/video).  The goal of unifying EPUB into the HTML5 / modern browser world is in fact to enable that “best of both worlds” – beautiful like a printed book and dynamic like a web site. And, with reflow too – while you pooh-pooh it, that’s part of making content work on different size screens (something the PDF as you know doesn’t do). We do have a long way to go still but I believe we will get there with HTML5 AND (not “or”) EPUB 3.

  2. EBook vendors enjoy a closed loop ecosystem. They have millions of reader/customers who are satisfied with ePub2 display capabilities and devices. Amazon readers, for example, are largely content with the offerings in the proprietary Kindle store; they’re not lining up with torches and pitchforks to push for improvements. While publishers wait for eReader device manufacturers to add new features and ePub3 support, eBooksellers are just as happy to wait.

    The best way to promote ePub3 right now is to bypass it in favor of delivering ultra-innovative books through the web and app-based distribution. When we can give eReader device makers a compelling reason to bring eReaders into parity with apps and webkit browsers, they’ll put their mouths where our money is. Until eBookstores know they’re losing sales to alternative/open channels, they’re going to sit pretty, stall, and make money doing what they’re doing.

Leave a Reply

Your email address will not be published. Required fields are marked *