Why we built an API

Several years ago I watched the talk Craig Mod gave on sub compact publishing at Books in Browsers. Based on his blog post of the same title and was one of those ‘aha’ moments when a few things you’ve been thinking about all click into place. His thesis was largely based on The Magazine at that point, run by Marco Arment which was built upon Apple’s new Newsstand technology. It was a reaction to the bloated interactive magazines that had started to fill up the Newsstand and called for a different approach to digital publishing, one that leveraged it’s strengths.

Nothing ever stands still and publishing magazines on the iPad never took off i the way predicted. However a few contenders for the long-form space soon emerged with ease and simplicity at their core. The most successful being Medium which has transformed long form writing and reading on the web. A couple of others have also appeared but made less of as splash. Hi, is a really nice platform which uses location as a means of discovery.

The way we deliver and publish books is the skeuomorphic equivalent of what we’ve always done with physical books. It’s a one way pipeline that pushes towards the retailer. A more modern and easier way for developers to adopt would be to use would be an API. Craig Mod elaborates more eloquently on this in his post here.

How does this fit into a book publishers web strategy? For years we’ve published extracts as PDFs, blog posts, flash widgets and all other manner of other ways. None of these have been particularly mobile friendly or allowed us to measure clicks to retailers or engagement with the text. The creation of a PDF chapter sampler was reliant on a person to create them so didn’t scale well as editorial assistants tend to be very busy and don’t have time to produce many.

Ebooks are just HTML and CSS wrapped up in a container, so it wasn’t a big leap to start using those to create extracts as webpages. This had several advantages. Scale, it allowed us to quickly add almost two thousand extracts over six month. Speed and efficiency, we built a very effective pipeline to add new extracts as a book published.

We can also do all the other usual things like heat mapping and tracking clicks to improve on the usability. Finally we could actually start to show how valuable extracts actually are to the business.

We didn’t just stop there as having a site gave us the opportunity to build an API at the same time. We’ve used this internally for several different projects. The most simple was adding an extract button to our websites through to a newly released WordPress plugin.

As we near the end of a new iteration the API has been bulked up more substantially to allow queries by genres as well as author, title and reading time. Whilst not the most complex API, its a small step for us to leverage the openness of the web and encourage others to share or use our extracts.

It’s a small iterative step, but one that gets us as a publisher closer to how the internet, developers and start ups work rather than how publishing does (currently).

Originally published at jamesluscombe.com on October 27, 2015.