How Apple does ebook widgets right
Apple’s iBooks platform is a rival of ours. Well, if you accept that Goliath was a rival of David’s. Admittedly there’s a disparity in our competitive relationship. When Apple feints in a direction — like, say, fixed-layout EPUBs — smaller players like Booki.sh have to keep our eyes on the blade. Whereas when we make a move — like, say, web-based offline reading — Apple can happily, safely (and to some degree, hopefully) ignore us.
For this reason we don’t particularly look forward to a major announcement from Apple about the future of iBooks, and by extension, their vision of the future of long-form digital content. Not because we fear being stomped on. We’ve long since stopped dreading that, any more than a remora fears the shark. What we worry about is that the long-term repercussions of Apple’s moves will eventually constrain our capacity to innovate.
Instead they’ve done it with microformats.
Apple’s various internal statements to the EPUB Working Group suggest that they have mixed views on this. Sometimes they do think books should have executable code.
But with the iBooks 2.0 widgets, they’ve taken the other stance. They’ve said: this stuff is up to reading software developers to implement. Like Apple. Or Amazon. Or Kobo. Or Booki.sh. What we need to do is give the ebook authors enough opportunities to customise the functionality, not recreate it for every single book.
This is exactly the right stance. We’re thrilled to see this, although it means a whole lot of work for us.
Why? Two reasons. First, yes, our easiest route is to just allow arbitrary scripting in ebook files. We don’t have to write a skerrick of code to do that. But this route introduces insurmountable security and user-experience problems, because arbitrary executable code is arbitrary.
As one of the smaller platforms, we are aware that publishers don’t develop their ebooks against Booki.sh reading software. They author them against iBooks (and Kindle, but that’s another format entirely). Unless we build an exact iBooks clone, there will be inevitable user-interface dissonance in scripted ebook content. For instance, some scripts will assume that books in landscape mode have a spine down the middle. For Booki.sh, those books would break in unpredictable ways. Our interaction model differs markedly from iBooks, and that will break a lot of scripted books too.
The second reason is that the ebook experience is kinda shit. For lots of reasons. It has been worse, but it could be so much better. Right now a bunch of smart companies, including Apple, and including Amazon with their KF8, and also including Booki.sh, are hammering away at that problem.
But if, while that work is going on, the publishers of the world are producing ebooks laden with executable code, those books will always be no less shit an experience than they are today. In most cases, they’ll degrade, as problems of backwards compatibility creep in.
A microformat-widget approach is totally different. I could take iBook Author’s emitted HTML and build basic gallery functionally into Booki.sh today. We could make that gallery great in three weeks, and after using it in earnest for a few months, we could even make it awesome. Apple is using the standard extensibility provisions of HTML5 — notably the
data-* convention. There’s nothing to stop us doing the same.
To all the innovating malcontents in the field of digital reading, Apple has paid an honest favour.
I guess it’s just a shame about that EULA.
— Joseph Pearson