The pros and cons of the iBooks 2.0 textbook format
This is the third post I’ve written on the iBook 2.0 textbook format. Previously:
There has been a lot of discussion on all sides on this new format Apple rolled out with iBooks 2.0. Some of it valid. Some less so. Some against all experimentation. Some not caring about standards at all. None of them change the fact that Apple has forked the ePub3 and CSS standards. It doesn’t matter if you agree or disagree, your opinion won’t alter reality.
One thing that bears mentioning is that almost everything ePub-related in the new format is completely standards-compliant. Where Apple has deviated it is not from the ePub format, but from CSS. Their widget format is, not as much a deviation from the standards, but a disregard of the standards and the philosophy of providing sane fallbacks for lesser reading apps.
Delivering a completely custom format has costs. Basing the format more cleanly on established standards would enable further code reuse, both authoring and rendering code, compatibility with other tools, and still enable Apple to gain leverage by rolling out features that its competitors can’t hope to match for months, if not years.
So, why do it?
Instead of getting into a tiff about it, I think evaluating the costs and benefits of the approach is more likely to deliver an understanding of why this has happened.
Note, I’m not getting into some of the issues with the iBooks Author app, as its limitations are not that of the format, and vice versa. Although, if Apple later on added support for ePub3 import and export to iBooks Author, that would solve a lot of the problems I mention below.
The cons
No fallbacks, no forwards-compatibility
Apple’s custom format, with a custom CSS layout model and bespoke widgets do not provide for much in terms of fallbacks for lesser reading systems, nor do they offer any future-compatibility with whatever ePub3 systems that might be rolled out.
These textbooks are tied to iBooks 2.0 on iPads. No iPhone support at the moment. No Android support ever. There’s no doubt that Apple doesn’t see this as a flaw, but for both publishers and readers, it is. A publishers have always had the option of selling their books in the iBookstore (or any ebook store, for that matter) DRM-free. This has allowed readers to move some of the books they buy to other platforms when they want. This is good for the reader at, despite what some publishers say, a minimal cost to the publisher.
This is no longer possible with the iBooks textbooks. The format doesn’t provide for much in terms of sane fallbacks for the built-in widgets or the layout features. Even if publishers had full documentation for the format and hand-coded their books, they’d still be hard-pressed to deliver a book with sane fallbacks for those using lesser reading systems.
The same applies if we look at hypothetical, full-featured, ePub3 reading systems that match, or closely match, iBooks 2.0’s capabilities. Because of the differences in the format, delivering a textbook that works sanely as a iBooks textbook and as a ePub3 book is difficult, if not impossible. Some of the issues could be solved through automatic conversion (the widgets, at least), but the CSS layout models is sufficiently different to thwart, in my opinion, most attempts at conversion. You’d have to implement the CSS layout twice.
This means that, unless Apple eventually adds ePub3 capabilities that match the textbook format to iBooks, publishers will have to implement interactive ebooks twice, and readers who buy interactive ebooks from Apple will be locked in iBooks.
This isn’t good for publishers. This isn’t good for readers. This isn’t good for authors. This is just Apple, being selfish.
Bespoke = legacy format from hell
One of the features planned for iBooks textbooks that doesn’t get much mention are updates. One of the core concepts is that you buy a textbook once and it gets updated by the publisher.
Congratulations! You have now bought into the legacy format from hell.
A format that doesn’t work with a publisher’s workflow, differs in important but subtle ways from standard formats, isn’t supported by any of the industry’s tools, is, long-term, going to be a torture to support.
Even if iBooks manages to build itself to a majority market position (by no means sure, given how tiny they are at the moment), publishers still need to support other platforms, and those platforms, by virtue of supporting open standards will have a much greater ecosystems of tools and processes to build on.
Even Amazon, with it’s custom Kindle formats, didn’t fork or extend CSS in incompatible ways, and it has pretty good support, with KF8, for ePub as an authoring format.
It’s less standards friendly in other ways, such as its deviations from the de facto standard fixed layout format, but Amazon’s crimes don’t excuse that of Apple’s.
In any case, with the new textbook format, Apple cuts textbook authors from a growing tools ecosystem that even Amazon is supporting. (The latest kindlegen has pretty good support for converting ePub files to KF8.)
The pros
Delivers capabilities beyond that of ePub3
One reason mentioned for forking the standard is that Apple needed to deliver capabilities beyond that of ePub3.
The ePub3 format allows for extensions and provides for ways of implementing those extensions with fallbacks for less capable reading systems.
So this simply is not true. The ePub3 format doesn’t limit them in this manner, and Apple could have easily addressed whatever limitations it had encountered, during the standards process, where they had a considerable influence.
Delivers an exclusivity that a standards-based format cannot
Also something I find hard to believe. ePub3 does allow, for example, for extending the format’s capabilities with widgets, so there’s nothing in the format that prevents competitive differentiation through new widgets. Apple deliberately didn’t use these capabilities in the iBooks 2.0 format. ePub3 also doesn’t limit the creator of a reading system from supporting cutting-edge CSS features, such as early draft standards, which enables a similar sort of system of experimentation as browser developers have been maintaining.
Apple could have provided all of the same features it did, using early drafts of CSS standards, instead of going off in a completely custom direction. This would have given them all of the same benefits of exclusivity as their current approach. Competitive differentiation does not benefit from completely forking the CSS standard when they could have differentiated themselves in standards-friendly ways, as they have done in the past with web browsers. Whenever Apple has extended standards with Safari, they have always brought their extensions to the W3 for standardisation, often well before the features are rolled out in an official version of Safari.
You’d think that this would kill off any attempt at differentiation, but despite this, Mobile Safari remains the best, most capable, mobile browser in the market, far ahead of the competition, even with the advent of Android 4.0. I don’t see why the same approach wouldn’t work with iBooks.
Standards are too slow
True. If you were talking about limiting yourself to Recommendations or Candidate Recommendations, then that’s very true. But nobody does that. There isn’t a single major browser vendor whose CSS support is limited to Recommendations or Candidate Recommendations.
If there had been no proposed standards, early drafts, or discussions in the CSS Working Group about delivering the capabilities that Apple requires, then this would be a very valid point. In that case, Apple would even be doing vital research work that would benefit the standards process later on.
However, this is not the case.
The CSS Working Group has been in discussion on advanced layouts for years and in 2011 it finally saw some progress in the standardisation process as both Microsoft and Adobe entered the fray with full vigour. Apple has been a full participant of this work, been clear about their needs and requirements, and has been fully aware of its progress.
As a result of the work over the last few years, there are now several promising proposals being discussed. Apple has no excuse for completely inventing a new approach. If they had needs that weren’t being addressed by the proposals they should have done more than just send one vague e-mail.
To wit: They could have implemented one of the discussed standards instead. Or, they could have helped fix the discussed approaches instead of going completely on their own.
Those who accuse standards bodies of being slow also don’t appreciate the IDPF’s phenomenal speed in putting together the ePub3 standard, a process where Apple was a pivotal member.
Who cares? iBooks still supports standard ePubs
That is not the issue at stake. Sure, iBooks supports standard ePub2 files, which are much more limited in the interactivity and designs they support. They aren’t going to remove support for that format.
The issue is that the new format raises questions about the future. As a member of IDPF and a participant in the ePub3 standards process, Apple seemed to be committed to delivering support for the new format.
Apple was the IDPF member that had come closest to delivering the features and capabilities of ePub3 with iBooks.
The idea behind ePub3 is that it would, finally, bring ebooks to a relative feature parity with the web and enable more advanced authoring and reading tools. The iBooks Author application is exactly the sort of app people expected would be brought to market as a result of ePub3’s capabilities. The iBooks new textbooks are exactly the sort of dynamic, interactive, and rich ebooks that ePub3 enables.
Now that Apple has decided to deliver both as a part of a custom format that throws the future of ePub3 into question. Apple isn’t an outsider who decided that a format somebody else didn’t have the capabilities it needed, it is essentially one of the format’s co-authors. One of the format’s biggest proponents and supporters has forked ePub3.
This is akin to Google deciding to build support for an incompatible fork of the HTML5 standard in Chrome after it had gone through the trouble of building consensus around the standard.
Will Apple add ePub3 to iBooks now? If they do, will they do a full-featured implementation that matches the capabilities of the textbook format, or will they just work like a warmed over ePub2 files?
What was the point of Apple’s participation in the ePub3 standards process?
No. I have to say, I still don’t understand why they did it.