Whenever a new technology is released it is, out of necessity, hyped to the maximum to ensure adoption, and if you're not taking this into account when thinking about ebooks, then you'd be forgiven for believing that HTML5, CSS3, and EPUB3, are the now and the future of ebooks. But I'm going to let you into a secret: there's plenty that these formats still omit, and for which they aren't perfect, and there'll be future iterations and updates that at times change things at a code level and will require the renewal of files to meet new standards.
'Drat!' I hear you say, 'I thought I'd finished messing around and could get on with new books not fixing old ones.'
Well if we took a step outside the HTML/CSS box, then perhaps we could stop all the fiddling around and get on with the work of publishing. (I'm talking here about treating the book as data and delivering via an API, see earlier posts on this subject).
How so?
Imagine having an asset in a format that can't be displayed in most ereaders and isn't part of the EPUB spec, because the work (or the licence fees) associated with support make it unrealistic and unnecessary to support in a regular ereader that'll be mostly used for fiction, but potentially inside a specialised app it would make the book so much more useful.
I'm thinking of a specialised video format, proprietary 3D design format, or something we don't know exists yet, but for some reason we might want it to be live inside the book for the highest level of readers, not just a static image, video or HTML 5 animation.
What difference does it make how we store and deliver the book?
Storing a book as data makes it easy to include assets that might only be supported in the future or by certain apps or devices (e.g. 8K video), and which won't require delivery to all devices. In order to deal with this the book data can have increasingly rich media attached to a single object and the app could select from the array of available assets which to download and display. It's as simple as writing this
{"image":["image.jpg", "image.tiff", "image.psd", "image.dwg"]}
(that's a complete and valid piece of JSON that could be easily parsed in PHP, JavaScript, Objective-C, etc.).
What else is there to say?
I've been writing, thinking and tweeting about the book as data a great deal, and to me it looks at present like the most obvious way to plan for the future of books is to think of them as data. After all, the delivery of content via API is already widely implemented in delivering social media "publications", so to extend this and utilise the tools already out there, which are tried and tested, and that developers are already used to implementing, makes absolute sense to me.
This is why publishers like Random House and Pearson have already started making their way down this road, and why others should follow and innovate in this space as well. Or, at least start putting plans in place and thinking towards this scenario.
Why does this matter to me?
At present we might all be talking EPUB, CSS, HTML and JavaScript, but these are today's presentational layer for digital books. In five years, things may well have changed dramatically, especially if the API element comes to fruition in the book world.
Meanwhile, there are already Android and iOS watches and glasses, in some cases in existence and in others on the horizon, for which CSS and JavaScript are likely to have very little utility, and it is already clear that the book will need the ability in future to 'scale' from very small to very large devices.
Meanwhile, there are already Android and iOS watches and glasses, in some cases in existence and in others on the horizon, for which CSS and JavaScript are likely to have very little utility, and it is already clear that the book will need the ability in future to 'scale' from very small to very large devices.
It is important then that we try as hard as we can to look through the digital mist and forward plan for books. After all this has always been the role of publishing, and there is no reason it should stop being the case just because we are moving into the digital realm in a more substantial way than ever before.
Comments
Post a Comment