I haven't blogged quite some time. The excuse is work, lots of it. But very interesting work.
Getting IGP:Distribution Manager deployed and working in a number of locations and languages; designing methods for large scale ePub production of art and heavily illustrated books; improving the subtleties of online typography in IGP:FLIP; and the intensity of creating the specification and software design for IGP:Content Fulfilment Systems with AZARDI II - have all taken a lot of clock cycles.
This post is not so much about ePubs, but what to do with the ePubs once they have been produced and our experiences with just that.
Nothing illustrates the Wild West nature of the current state of digital publishing than dealing with the people, protocols, ad hoc rules, and quirky file packaging of a few dozen e-book retail, wholesale, search and library channels. It's an attention to detail challenge peppered with fast-draw responses to ad hoc situations and changes.
Every distribution channel is like a remote town with its own sheriff and hanging committee. They are all oblivious to each other and at the edge of the towns there is that irritating "king" of the plains, Amazon; riding rough-shod, and milking everyone's cows for all they are worth while they can. (Yes. I was a Louis L'Amour fan some 40 years ago!) A hero is definitely needed here!
Now away from allegory alley and into the gritty details of bulk e-book distribution.
ONIX
ONIX is one of the highlights of the distribution business. Where it is used ONIX metadata generally works well and the Yahoo group ONIX_IMPLEMENT is responsive, informed and proactive.
ONIX is good, ONIX works, but ONIX is complicated. It is not easy for a smaller publisher to handle any ONIX strategy, let alone one where 14+ (and growing) different ONIX variants have to be created to exploit all the sales channels. There is also the non-backwardly compatible ONIX Version 2.1 to Version 3.0 transition complicating matters for implementers at both ends of the messaging system.
As an information interchange standard ONIX is pretty robust and has a solid history. The implementations at the receiving end are not always so robust, and there are usually back office humans compensating for lack of automation, and running various submission checks. Right now the complexity of the ONIX required for a successful digital distribution event is not overwhelming.
What is challenging is that to send a distribution package to 14 plus retailers and wholesalers means 14 variants of the ONIX covering rights, currency, language and Sales Taxes, and in some cases additional custom metadata fields and (yuck) spreadsheets of enormous column complexity.
The fact is it is pretty much an ONIX world. So much so we are developing a new product, IGP:ONIX Online. This specifically targets the ONIX creation, messaging and channel ability complexities and problems faced by SM publishers. It can also help publishers trapped with ONIX or in-house solutions for generation of print distribution ONIX, which can't produce multiple ONIX files in the required prescriptions.
IGP:ONIX Online is not and will not be a comprehensive ONIX solution. It is focused on addressing the digital content distribution problem set only. The output is the creation of multiple ONIX files for multiple distribution channels, with multiple currencies, in multiple regions with multiple rights profiles. It integrates directly with IGP:Distribution Manager. It also has to handle non-ONIX metadata fields where they are needed, and non-ONIX packaging for the likes of Print on Demand vendors.
Packaging
Getting the ONIX and "other metadata" right are around half the problem. Every channel has at least some small subtle variation on how the files are to be presented when uploaded. Directory structures, file-naming systems, to zip or not to zip, relative placement of covers, e-book files and the compilation of metadata. More irritating channels also require multiple delivery locations and non-ONIX metadata.
You think you have seen it all, and the very next channel we add has yet another rule. It demonstrates that truism "any finite set of data has an infinite set of interpretations" and establishes the primary purpose of IGP:Distribution Manager; enabling a publisher to get a book to a digital fulfilment channnel without having to know the agonizing details of the delivery mechanics.
New Business Strategies
Digital book distribution highlight some interesting new business possibilities for Publishers. In the plodding world of paper books, once an RRP (SRP) is printed on the cover, it is pretty permanent until the print-run is sold out, remaindered, or offered on sale.
Digital distribution offers the opportunity for new marketing strategies with pricing and promotion variations by region, currency and for controlled periods. It's not just the content that can be dynamic. Digital product pricing terms and conditions are all well captured in ONIX 3.0. Now we have to wait for the e-retailers ability to support these powerful business features.
This highlights the fact that currently digital content strategy thinking is largely a replication of the paper publishing business, just a lot noisier and more confusing. That is quite understandable given the fast paced growth of digital content uptake and proliferations of device reading options in just a few short years. Our job is to provide the tools that reduce the confusion and at least let an SM publisher have a fair shot at a transition to digital publishing.
The coming changes are not just about the current crop of dedicated e-book readers and controlled distribution channels. 2011 will see the rise of Android, MeeGo and other app supporting mobile and tablet devices that present stunning new content distribution options and value addition options for publishers.
LOTE
There are increasing complexities for non-English eBook distribution. Interestingly most interest for the IGP:Distribution Manager product is from non-English countries (for whom Amazon remains a river in Brazil, and Kindle small twigs to start a fire), who also have different device issues to address and their own particular character sets.
ADE handle this abominably and require fonts to be embedded or handled in the device. iPad and Kindle both do a tradesman-like job on both Latin's Extended A and B, plus other generally useful characters. However most LOTE countries have at least one digital content retailer serving their language communities in some format or other.
Comments