• Print

Ebooks as native apps vs. web apps

Our two experts wrap up their debate on the best path towards richer content

Over the past week I’ve posted excerpts from a very insightful email exchange between Bill McCoy of the IDPF and Sanders Kleinfeld of O’Reilly (first piece here and second piece here). This is the final installment of that thread and we pick it up where Bill suggests a tighter connection between the simple ebooks of today and the richer ones we’re likely to see in the future:

Distinguishing ebooks from apps

Bill: There’s a continuum between non-enhanced text-centric publications and enhanced interactive publications, not a dichotomy.

Sanders: Well, I think you always need to draw a line somewhere between “ebook” and “app”. That’s true right now, in that “Finding Nemo: My Puzzle Book” is an app and “Does the Noise in My Head Bother You (Enhanced Edition)” is an ebook. My current prediction is that in the future, the line is going to be drawn such that more and more content slides over to the “app” side, and more specifically that more of these will be web apps, as opposed to the native iOS/Android book apps that predominate now. It sounds like you believe the reverse will be true, and you may very well be right.

Honestly, I just want publishers to put out more and more awesome, innovative digital content, preferably crafted using open Web standards. If it’s easier for them to do it using EPUB 3, then I’m all for it. But if circumstances militate against this route, as they do now, I’d rather see them explore web apps than throw in the towel.

Bill: Your argument would seem to imply that if you need to add a video or an equation visualization widget to an eBook you should move to the “other side” and build a web app instead. That’s not realistic for publishers. A lot of content will bring limited enhancements to largely text-centric linear documents.

Your own “HTML5 for Publishers” may even be a good example. It obviously has a lot of enhanced capabilities. It can live as a web app but as far as I know it doesn’t, or if it does it isn’t the normal way it’s consumed. And if you did make it into a standalone web app you’d have to code up a whole skeleton of supporting infrastructure around it, using non-standard tools. Do you really expect every publisher to do this for every title?

Sanders: I disagree with this point, in that it implies that in circumstances where you want to add a video or another widget, it’s necessarily a lot of additional work to do a web app than an EPUB 3. There’s no reason why you can’t take the very same content that you zip up in an EPUB 3 and instead post it wholesale on the Internet as a website. And if you did want to add additional supporting infrastructure for a title, it could likely be reused for other titles; I don’t think it’s true that publishers would have to start over from scratch for every book.

Bill: And a whole lot of content is going to be less enhanced than “HTML5 for Publishers” (since after all it’s subject is interactivity). I think any title being created today with iBooks Author and Habitat will be doable with off-the-shelf EPUB 3 based tools and deliverable to multiple off-the-shelf EPUB 3 reading systems within the year.

Sanders: That’s great. I really do hope that proves to be true.

Closing the gap between HTML5 and EPUB 3 support

Bill: We are still in the initial rollout stage of EPUB 3 support. As EPUB 3 proliferates, there’s no reason for EPUB 3 support to continue substantially lag browser support.

If I thought reading system implementations would remain well behind browser stack level capabilities forever, that it wouldn’t become normal to expect to deploy the same wide variety of JavaScript libraries in an interactive ebook as in a web app, I’d be less positive. But I see things converging to a model where everyone will be using WebKit, in many cases the same one that the platform’s web browser is using, so no reason that it should be any less feature-rich. iBooks is already there, and things that work in browser-based web apps that are disabled there are only for business or security considerations, and I view the former as temporary. We’re catching up more than 10 years in one transition – it’s painful that it’s taking over a year to accomplish but that’s no reason to presume it won’t be successful. In fact I’d much rather have your help getting us there than having you arguing that we shouldn’t bother. But maybe I’m misunderstanding your POV and would welcome your thoughts and feedback.

Sanders: It’s great to hear you say that. I do acknowledge that my perspective on this debate may be overly biased by my experiences as an ebook developer for the past year, who has been greatly frustrated by the current state of the ereader landscape’s support for HTML5 features and how much it’s limiting innovation in the EPUB (and Mobi) space. But I know you’re traveling all over, fiercely advocating for EPUB 3, HTML5, and open Web standards, and have a much better perspective than I do where things are headed, and how fast we’ll get there. I’m not sure what you’re advocating publishers do in the meantime, though. Should they just wait? Should they predicate their digital publishing initiatives on whether NOOK will support Canvas in the next year?

I have a great deal of admiration for the IDPF and their mission to achieve broad-based support for EPUB3, and I most certainly regret that anything I said may have diminished the value of this goal or argued against it. At the same time, I hope it’s understandable why publishers might view putting all their eggs in the EPUB 3 basket to be undesirable at this time.

I believe this statement by Bill was one of the most important ones in the whole discussion:

As EPUB 3 proliferates, there’s no reason for EPUB 3 support to continue substantially lag browser support.

That lag is one of my biggest concerns as well and why I feel publishers should focus on HTML5 itself and not something else that’s built upon HTML5 (and therefore requires more time for development and adoption).

What’s your opinion? Will the gap between HTML functionality and EPUB reader support for those features shrink or will there always be a lengthy delay in the latter’s ability to keep up with the former?

tags: , , , , , , ,
  • Russell Jones

    The gap between HTML functionality and EPUB reader support *may* diminish over a long period of time, but in the short term (e.g. the next five years), that gap will remain, because we’re discussing two different specifications and multiple ereader manufacturers/implementations, who have little incentive to make all their capabilities match up. You can see why this is true by taking browsers as an example. Even *now,* browsers are not all completely compatible. That’s true even if you look at only the most current versions of the most popular browsers. For ereaders to even gain the capabilities of current browsers will take a long time. For them to all work the same way with the same content will take even longer. And that’s not even consdering the specifications themselves, which are not likely evolve in lockstep or even necessarily in the same directiion.

  • http://www.facebook.com/people/Frank-Lowney/1269417539 Frank Lowney

    I wonder if publishers are the right people to be “enhancing” eBooks.  I feel that this can only result in gratuitous decoration.
    The author is the only actor who can integrate text, images, linear media and interactive (non-linear) media in a coherent, meaning-enhancing  fashion.  However, authors need tools that allow them to use these modes of expression without the distraction of having to work with raw code in a text editor.  
    I am impressed with the Apple Pages ePub template and imagine it being extended to include fixed layout and even read aloud.  In this environment, an author can consider the work holistically and that is critically important to innovation.  
    Thus, we should be building these tools for authors, not publishers.

    • Russell Jones

      Authors already have (or have access to) the same tools that publishers do–if they want them. The problem, though, is that once you get into the realm of “enhanced” eBooks, the skillset required increases immensely. As one simple and common example, translating a book to a different medium–for example, film, requires enormous numbers of people with different skills. Another “story based” technology is video games, which require even more people than movies to produce. And of course making a program requires programming skills–and depending on what sorts of enhancements you’re interested in, may require multiple types of programming skills, plus graphic art skills, digital video production and editing skills, makeup, actors, animation, voice talent, game creation skills, algorithmic knowledge and application. All in all, I think expecting that authors will acquire sufficient skills to create and integrate all this content is simply not likely.

    • J.B. Bird

      iBooks Author as it now stands is not the answer BUT the iBooks Author model is the right direction – a user-friendly WYSIWYG tool that puts the power where it needs to be,  in the hands of the content creators. Imagine if iBooks Author could generate ePub 3-style interactive documents (which it can) that could be read on all tablets, PCs, Macs, and current-gen eReader at Kindle Fire level on up (which it cannot). That is what we need – a WYSIWYG ePub 3 content tool, or, in the tradition of Western economic innovation, two or three outstanding, competing tools. InDesign is not there – clearly, this is an issue with the platforms, and with many levels. But at the end of the day, what we need can be summed up like this:

      iBooks Author-like tools that publish on multiple platforms.

  • Ggg

    “I think any title being created today with iBooks Author and Habitat will be doable with off-the-shelf EPUB 3 based tools and deliverable to multiple off-the-shelf EPUB 3 reading systems within the year”.
    Really ? I’ll believe it when I see it.