Booki.sh is your ebook library in the cloud, accessible from anywhere and almost anything. Learn more, or start reading a wonderful classic ebook right in your browser.

24 January 2012

A favour from Goliath

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.

So we were surprised and delighted by some aspects of the .ibook file that iBooks Author spits out. Their extensions to EPUB are done precisely the right way. They’re not done with dollops of embedded JavaScript — a fact that Baldur Bjarnason laments. (You can be sure EPUB’s governing body, the IDPF, is lamenting that too.)

Instead they’ve done it with microformats.

There’s a philosophical division at the heart of ebook formats. Which functionality belongs “to the ebook”, and which belongs “to the reading software”? Bjarnason and the IDPF say the functionality of an image gallery, for instance, should be coded line by line into the ebook itself. Each ebook should contain arbitrary executable JavaScript code.

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.

That’s the first reason we’re thrilled about the widget-microformat approach iBooks is taking — we can build to the spirit of the functionality, rather than just mimic the functionality. We can parse the intention of a microformat — it’s impossible to parse the intention of a chunk of JavaScript. We’re not forced to build an iBooks clone, which work would hold no attraction for us.

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.



Update: Bjarnason rightly points out that his argument about what Apple should have done with .ibook is more nuanced than ‘embedding dollops of JavaScript’. Worth reading his follow-up.

— Joseph Pearson