1. Enable developers to access, via an API key, preview versions of every book you publish for their (web) apps
These previews will include metadata and index, all chapter headings, a short amount of text, etc. The index will allow online discovery of further content, enough for the potential purchaser to evaluate the book. The API key will help track and identify the developer, so that you can record the level of traffic and revenue they generate.2. Allow the user of a developer's app to purchase the entire text through signing into the publisher's website within the (web) app
Doing so through the publisher's website will mean that not only will the user have access to the book within any app they use that is linked to the API, but the developer will receive a percentage of the purchase price. An alternative to this system would be one in which the developer can choose to be billed for user purchases, this would be useful in situations such as in-app purchase where the developer will receive payment from elsewhere.3. Think of developers as booksellers, and publishers as content creators and copyright holders
In the first instance developers should be incentivised to sell your books by a generous percentage of the selling price, but put in place enough security to help identify illegal storage and sale of books that circumvents the publisher. If the relationship works well then developers will be like booksellers that actually get to shape the appearance of your publications inside and out (but like all business relationships this will require mutual trust and respect, not paywalls and barriers).In conclusion
What I'm proposing here is a situation where publishers create content and app developers take that content to do what they do best, which is to shape it into an immersive experience. The reader would be able to pick and choose their favourite app, enjoying the freedom to move between apps and devices on their own terms.Note: I wrote this post having read McGuire's article (see further reading) but before seeing Oliver Brooks' piece in the 'Best of TOC' publication. There are strong similarities between the conclusions I arrive at here and Brooks' position. I highly recommend that you read the short article by Brooks to further enhance your understanding of the API approach and the possibilities it provides.
Further reading
Oliver Brooks, 'Buy Once, Sync Anywhere', Best of TOC: Analysis and Ideas About the Future of Publishing, 3rd Edition, O'Reilly, Feb 2013, pp. 71-77
Pablo Defendini, 'TOC, APIs, and Streaming Books', 18 Feb 2013, Safari Books Online [this was posted a few days after this post originally went live.]
HarperCollins, OpenBook API
Hugh McGuire, 'A Publisher’s Job Is to Provide a Good API for Books: You can start with your index', 1 Feb 2013, Tools of Change for Publishing (Website)
Pearson Developer, APIs
Random House, Rest Services API
Wendell Santos, 53 Books APIs: Google Books, Goodreads and SharedBook, 13 March 2012 (via @hughmcguire)
Pearson Developer, APIs
Random House, Rest Services API
Wendell Santos, 53 Books APIs: Google Books, Goodreads and SharedBook, 13 March 2012 (via @hughmcguire)
Comments
Post a Comment