ENTRIES TAGGED "Habitat"
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.
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?
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.
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?