Russell Beattie

Apple launched their new iBooks Author and iBooks 2 apps today. After I watched the keynote video, I downloaded everything, and some sample books, to try out and see what they came up with. The new book format is pretty nice and has some interesting features, but honestly, it's nothing that a decent web developer couldn't do with HTML5. That's the point of course - that you don't *need* web developers to create great looking interactive books, and that's great.

But then I read about Apple's onerous restrictions to their iBooks Author app (you can only use it to create books for iBooks), and like everyone else in the world (except Apple execs it seems), I was completely disgusted. All the talk about opening up tools for educators, etc., only to turn around and mandate a lock-in for publishers who use their tools? Soooo cynical. No wonder they only had 8 demo books to show.

This made me think, why don't we have an open standard yet where this isn't even a issue!? HTML5 is here, developers are behind it, and it's supported by every browser vendor out there. Why can't you just take a bunch of basic web files - html, css, javascript, images and video - and throw them into a zip file and call it an eBook or an App?

Well, you can. Sorta. Well, not really. The problem is that it's too obvious of a solution, so *everyone* has a version of this sort of thing...

Microsoft has had their 'compiled HTML' .chm files for about a decade now, and their newer .mshc (Microsoft Help Container) format is now simply a zip of XHTML files. Then there are the various 'widget' formats for both desktop and mobile (promoted by the W3C) which are all zipped web files. The ePub guys, Amazon and Apple have their slightly different versions of the idea. Mozilla Labs has their Apps initiative, and Google's Chrome Apps have their version (again, just zipped web files). There's probably dozens more just slightly incompatible file formats I'm missing.

I can sort of understand why this happened. First, you need to have some sort of standard manifest file to hold the meta-data about the app (it's name, thumbnail, version, etc.), then you need some added APIs for access to device features that don't usually show up in a browser (files, wireless, sensors, etc.), and you need some sort of security sandbox, and then a permissions list - which leads back to the manifest, which may need to include some sort of hash now to prevent tampering. Gah!

So much for 'just zip the damn web files dammit' way of thinking.

But all that said, this stuff is all being done, right? It's just being done a bit differently by different groups, each with a slightly different focus. Amazon isn't trying to re-create Angry Birds in their new Kindle format, so it doesn't have any sort of access to Javascript. Google isn't thinking about eBooks per-se, so their Chrome apps have all sorts of APIs as well a way to run native code. The W3C? Well, they're all over the place with the 'widgets' spec - the problem being that widgets never took off on the desktop, nor on the mobile phone, and they're poised to fail dramatically on the tablet as well. And HTML5 spec itself? Well it has the cache manifest file which can be used by browsers to take apps offline, but doesn't specify any instructions about file container formats (like, say, a zip file).

So again, it's being done a million different ways, it just needs organization and cooperation. And not in the 'here's 20 different levels of specs' sort of organization, but a 'here's the simplest thing that could possibly work' sort of organization so that it's implemented before another decade rolls around.

Maybe the HTML5 group could add something simple to the spec? At the bottom? In small type? That'd be a great start I think...

-Russ

Update: Amusingly, it looks like I basically reiterated what Tobie Langel said a month ago about App Manifests - only his post has more specifics and couple more examples. :-)