• Print

HTML5, EPUB 3, and ebooks vs. web apps

Two experts help us navigate the ebook format jungle

One of the benefits of working on TOC is that I get to see some of the behind-the-scenes industry debates that take place via email. Since it’s “formats” month here in TOC-land I thought it would be fun to share a thread about HTML5 vs. EPUB 3 featuring O’Reilly’s Sanders Kleinfeld and the IDPF’s Bill McCoy. They’ve both agreed to share this thread with the TOC community since it helps clarify the state of both EPUB 3 and HTML5.

It all started with an HTML5 interview I did with Sanders earlier this month. Bill reached out to Sanders as follows:

Your mileage may vary, especially on the Nook

Bill: Your interview with Joe for TOC was interesting. As you know from prior discussion I totally agree with you that the current situation is sub-optimal. It’s disappointing that nearly a year after EPUB 3 is out, B&N’s flagship tablet device doesn’t support EPUB 3 yet, even though it ships with a reasonably modern browser that does support HTML5. This is due to delays by their current vendor for eBook rendering software (Adobe) rather than a lack of desire on B&N’s part, but it’s still a problem. I also agree with you that where EPUB 3 is supported like Apple iBooks and Kobo the consistency in terms of being able to safely use leading-edge JavaScript libraries and other browser-stack features in disparate reading systems is not where it needs to be. While it’s true that EPUB 3 needs to be able to be supported on limited capability devices I think we didn’t help by making so many things optional and being silent on reading system support for various APIs that are de facto part of the browser stack but not officially part of the HTML5 spec normatively referenced by EPUB 3 spec (e.g. geolocation, local storage, XMLHttpRequest).

I also agree with you that Web-technologies-based apps are the future for experience delivery, both in browser and increasingly for native-class apps that are liberated from the browser (whether wrapped in PhoneGap or CEF, W8 Metro apps or the new Chrome Packaged App model Google rolled out this summer at I/O).

Sanders: Yes, I think what I find so frustrating is that we’ve got tablets on the market like the Nook, which use two different engines to render Web content–one for the Web browser and one for the ereader–and the ereader is lagging so far behind the browser in HTML5 support. The ereader is being treated like a second-class citizen, even though it’s ostensibly the primary feature of the tablet (or at least the primary feature by which the tablet is being marketed; I concede that there are many people buying the Nook who just want a low-cost Android tablet, and have no intention of reading ebooks on it).

One of the things I appreciate most about iBooks is that it uses the same Webkit engine as Mobile Safari, and if you test the same HTML5 content in Safari and in iBooks, you usually get the same results.

Distinguishing apps from ebooks

Bill: But… despite all this violent agreement… I’m having a hard time with your contention in the interview that “a lot less is going to fall in the eBook side than it does now for enhanced text and graphics… anything that’s more enhanced is going to drift over to the app side… we’ll have  our standard EPUBs for fiction/nonfiction and then biology textbooks will be on the other side”. That’s what I want to probe on in this email.

Sanders: I’ve thought about this quite a bit after my initial conversation with Joe, and I think the debate of “ebook” vs. “app” can be pretty facile if you’re not careful about how you define those somewhat loaded terms. And I think I failed to do a good job of that in my interview. So let me step back and try to do better now.

If you define “ebook” as “something that can be represented in EPUB 2/3 or Mobi format and rendered in an ereader app”, and you define “web app” as “something that can be rendered in a Web browser and/or sold in an app store”, then you’re really just arguing about packaging, not the underlying content, because an EPUB 3 file is composed of HTML5, CSS, and JavaScript, just like a web app. In the quote you cite above, I wasn’t really trying to make an argument about packaging, as much as about the kinds of electronic media that publishers are creating right now, and will be creating in the future.

I think Phase 1 of ebook creation for publishers was basically, “Let’s take all our print books and digitize them so they can be read on a Kindle or iPad”, without much in the way of innovation in terms of interactivity, customized rendering for a reflowable context, or even hyperlinking.

I think we’ve now graduated to Phase 2, where publishers are thinking, “How can we make customized digital content for tablet devices, instead of plain-old text-and-graphics ebooks? Do I make an ‘app’ or do I make an ‘enhanced ebook?'” I think publishers are generally taking two approaches to this:

Approach #1: Hire on software developers to make full-fledged native apps they can sell in the app stores for iPad/iPhone/iPad and Android (lots of these are children’s titles, e.g. “Finding Nemo: My Puzzle Book“)

Approach #2: Make an “enhanced ebook”, which takes the standard Phase 1 text-and-graphics context, and then grafts on some multimedia features, like audio and video clips (here I’m thinking of the Steven Tyler memoir “Does the Noise in My Head Bother You (Enhanced Edition)“, which was featured prominently in Ana Maria Allessi’s talk at Editech)

I’m rather against Approach #2, because I don’t think it’s especially innovative, and I don’t think it’s what customers really want out of next-generation e-content. I feel like the whole notion of “enhanced ebooks” is somewhat of a transitional concept, as publishers start making baby steps in rethinking how they produce content for a Digital First world. In the long term (next 5 years or so), I think a large part of the “enhanced-ebook” middle ground is going to go away, and ebook content is going to fall more neatly into one of two categories:

Category 1: The standard text-and-graphic content that you can read on even the lowest-end eInk ereader (because I don’t think all-text fiction/nonfiction is ever going to go out of favor)

Category 2: Everything else, which will be more and more app-like in the sense that it will be highly interactive, to-some-degree social (commenting, linked to Facebook/Twitter, etc.), and conceived from the start for a Web context (densely hyperlinked, with sophisticated mechanisms to search content and navigate it in a nonlinear fashion)

So, that’s what I was getting at above; I just wish I had articulated it better in my interview.

That’s just part one, folks. Stay tuned later this week for excerpts from the rest of the thread where Bill and Sanders talk further about the subtleties of EPUB 3, HTML5 and web apps.

(Update: Part two can be found here and part three here.)

tags: , , , , , ,

Comments: 14

  1. The Nook Tablet is the most disappointing device I’ve ever owned. I’ve given up on the EPUB reader, the PDF reader, the browser, the app store and just about everything else about it. The best advice I can give anyone is “if you want to read eBooks on a tablet, buy an iPad or an open Android tablet like the Nexus 7 or Samsung Galaxy Tab.”

  2. Hi Joe – Based on Sander’s comments, Category 2 is the “enhanced” wave of the future.  Tablet and e-reader ownership is pretty fragmented, and it seems like HTML5 is the only platform that will be capable of delivering app-like experiences on a wide range of devices.

    I think the new Amazon tablet and e-reader line (Paperwhite, Fire HD) is awesome, but it’s strange that KF8 doesn’t support HTML5 embedded video or audio.  Do you think there’s a strategic reason for that, or do you think we’ll soon see KF8 supporting more HTML5 elements like embedded video/audio?

    • Hi Ben. I figure everything Amazon does to limit certain functionality is for a strategic reason. That’s purely speculation by me but I feel it tends to be true.

      • Hi Ben/Joe,

        I think there’s likely a technical component to the current lack of support for audio/video in KF8. Amazon has a diverse ecosystem of ereaders–including its Fire tablets, a variety of eInk devices, and software readers for PCs and smartphones–which makes feature rollout more challenging and makes it harder for them to iterate on software releases as quickly as Apple/iBooks. Amazon has gradually been adding KF8 support to more and more platforms (now including the latest-generation of eInk readers), and I suspect there’s a long-term plan for adding widespread audio/video support.

        That said, I’m still a bit puzzled on delaying audio/video support in ebooks for Kindle Fire, specifically. Why cede that competitive advantage to iBooks and NOOK tablets? Makes you wonder how significant today’s current crop of embedded-video “enhanced ebooks” really is to the ebook marketplace.

        • “That
          said, I’m still a bit puzzled on delaying audio/video support in ebooks
          for Kindle Fire, specifically.” The major use cases for a Kindle Fire are:

          1. Reading books – plain old mass-market books and text.
          2. Watching one of the thousands of movies available.

          Everything else – playing music, magazines, textbooks, games, … is secondary. Amazon have a huge collection of usage data from the millions of Kindle FIre units out there.

        • Hi Sanders,

          Here’s a bit of background:

          I’ve had a Kindle for about a year and have loved reading ebooks on it.  Fast forward up to this month.  I watched Jeff Bezos’ 1hr+ promotional event, and I was particularly inspired by Kindle Direct Publishing segments.  My Mom has written several books (paperback) and I’ve always thought of writing.  I’m now really attracted to the idea of direct publishing to a platform that gives me access to great hardware (Fire HD and Paperwhite).  But as I’ve dug deeper, I’ve found that format constraints may restrict my creativity.

          It’d be interesting to investigate if KF8 could improve by adapting to its playback device.  Authors could choose to add embedded video/audio (which would work fine on Fire HD) to their KF8 book, and if the consumer’s playback device isn’t capable of handling this, a secondary layout could be substituted.  For example, an author would be required to add hyperlinks in addition to embedded audio/video files, and if the device can’t support embedded then it could fall back to hyperlinks.

          Just some ideas.  I’m not a digital publishing guru so I could be way off here 🙂

          • You’re not at all far off, Ben. There do exist standard mechanisms for providing fallback content for browsers/devices that don’t support the HTML5 audio/video tags; you just embed the fallback within the or tag. This is pretty common practice on the Web.

            Whether publishers concertedly pursue the fallback route, however, and whether ereaders implement them properly (many do) is another question, but I agree completely with you that this is the direction in which we need to be headed, because it’s the main way I see to bridge the eInk-tablet divide without resorting to lowest-common-denominator digital publishing that eschews interactive/multimedia features, or just publishing only to platforms that support the interactive/multimedia features you need.

          • Can you be compliant with EPUB 3, or HTML5 for that matter, and not support the tags, though?

            A reading system may not render audio or video content, but that’s different from not supporting the tags, which is what the internal fallback is for.

            It also greatly complicates accessibility, as if you put fallback content inside the elements, a device won’t have access to it in normal rendering contexts to pass on to an AT, hence the warning in the HTML5 specification not to use it for this purpose.

            I don’t have a better answer, beyond typical suggestions like linking to transcripts, etc. I think the proposal still under review to consider a linking mechanism to a transcript would be a good move to clean up the interface and provide a programmatically determinable way to access the information.

            But transcripts only work best where the audio/video is solely imparting information. A comparable experience for entertaining content eludes me, at least without scripting support so you could show/hide content based on whether the audio/video content is playable. I’m kind of sceptical that eInk devices will enable scripting, which kind of throws that idea out the window.

            I agree that decisions shouldn’t be made on what a device at any point in time is capable of, though. This is just a hard one to answer.

  3. Now we have the new iphone 5!

  4. Thanks for such an insightful article from credible sources. I’ll definitely be looking forward to some more legit news 🙂

  5. What I have discovered so far is that the iPad reader is the best behaved for epubs using HTML5. The Nook reader recognizes the audio and video tags but the player stops when you turn the page (the iPad doesn’t). The Nook Reader app on the Kindle crashes when it encounters a page with an audio or video tag.There doesn’t appear to be any hook in the Kindle Fire HD that allows you to embed these tags in any epubs. I have not found an epub reader for the KF that completely supports HTML5.

    • Thanks! That’s actually not a great surprise. Building “universal” eBooks and players is an expensive process, as “Accessible EPUB 3″ documents well. So the name of the game is engineering economics – internal rates of return, payoff period, time value of money, etc. Apple / iOS has the cash and profitability to make a better EPUB reader than Amazon, Sony or Barnes and Noble.

      On a related note, I haven’t found any device smaller than 10″ that does even an *acceptable* job of viewing PDFs. So I am stuck with my laptop as an eReader more or less forever. That’s too bad, because a lot of the PDFs I read are scientific papers coming out of LaTeX tool chains that *could* be played easily on a 7” tablet with reflow, tables and figures with only a modest amount of code. Engineering economics, again.

  6. This is an excellent conversation – it’s really a shame that this battle still rages. It’s also worth noting that Apple has routinely denied apps into their Appstore for being too “book-like.” So even if an author went through the trouble of making a media-rich app with a developer, they likely would never see their product to fruition…so content producers are essentially left with (1) ePub 3 or b) website….

Leave a Reply

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