ENTRIES TAGGED "API"
Applying data viz techniques to study how a project evolves over time
Data visualization is one of the hot topics of the last year or two. So what does this offer publishing and book production?
Open data activists in particular have been lobbying governments for access to databases which they use to create infographics and visualisations for campaigns. It’s not a new science of course, it was here long before the net (for some background on contemporary practice see the wonderful books by Edward Tufte) but the net is made of data and a good mechanism for transporting it. The net is a good medium for scraping and re-presenting data in more palatable forms. Read more…
It's time to get a grip on the fragmentation of digital books
While building ValoBox we’ve been working with a number of publishers. We’ve been asked a number of times about the potential for publishers to integrate ValoBox more closely into their existing direct retail channels such as a ‘Read now’ button on their eCommerce site. This has been an intriguing element to look into, particularly as it goes to the heart of what we are really interested in: making the content within books more accessible. Our platform does it through enabling browser-based reading and micro-purchases, but it got us thinking of ways to solve the wider problem of paid content fragmentation.
The connections between readers and potential readers matter most
I spoke at the “Frankfurt Digital Night” at this year’s Frankfurt Book fair, making essentially three points (see slides embedded below): first, publishing requires – and has always required – a commitment to creating and courting communities of readers. Second, there are new digital tools emerging for creating and courting these communities. Third, in this context, openness in terms of APIs is becoming a feature.
Doing business by relying on the kindness of strangers
‘Open API’ is a well-known term that seldom gets challenged. It passes in conversation as an agreed-upon good. However it should be recognised that there is no such thing as an Open API – it is a euphemism for a specific kind of technical service offered with no contractual agreement to secure those services.
It's still wise to focus on what you do best and outsource the rest
For the publishing community, social reading has been the hot topic of the year. Since 2008, in fact, social features have spread like wildfire. No publishing conference is complete without a panel discussion on what’s possible. No bundle of Ignite presentations passes muster without a nod to the possibilities created by social features. I understand why: in-content discussion is exciting, especially as we approach the possibility of real-time interaction.
Granted, I’m biased. Running a social service myself, I think all this interest is great. The web should take advantage of new paradigms! Social discussion layers are the future! However, there is one important point that all the myriad new projects are ignoring: unless it’s a core feature, most companies shouldn’t build social.
That’s right. Unless social discussion features are the thing you’re selling, don’t build it from scratch. What’s core? Your unique value proposition. Are you a bookstore or a social network? A school or a social network? A writing community or a social network? A content creator or a social network? The distinction is often lost on a highly-motivated team trying to be all things to all users. For all these examples, the social network is just an aspect of the business. It is an important piece of the experience, but most of the time it’s not worth the incredible investment in time and manpower to build it from scratch.
Services, APIs and the Complex Web
We’ve seen this happen again and again on the web. If you’ve ever heard of Get Satisfaction or UserVoice, you’re familiar with the evolution of customer service on the web. Ten years ago companies built their own threaded bulletin board systems (and managed the resultant torrent of spam), so that they could “manage the user relationship.” There were some benefits – you could customize the environment completely, for example. But it took the greater portion of a week to build, and a lot of work to maintain. Today that kind of support can be up and running in an hour with third party solutions. Just ask forward thinking companies like Small Demons and NetGalley, who have embraced these services.
The same can be said of newsletters. For years newsletters were hand-coded (or text-only) and sent from corporate email accounts. Unsubscribing was difficult. Getting email accounts blacklisted (because they looked like spam) was common. Today everyone uses MailChimp, Constant Contact, Emma, or a similar service. Even if you hire an agency to design and manage a system, they’re likely white-labelling and reselling a service like this to you. Companies no longer build a newsletter service. Now you just use an API to integrate your newsletter signup form with a third-party database. Design your newsletter using one of their templates, and let them do all the heavy lifting for email management, bounces, unsubscribes, and usage stats.
There are other examples. Who stores video and builds their own player? Instead we upload it to Vimeo, Brightcove or YouTube, customize the settings, and let the service tell you who watched it, handle storing the heavy files, push player upgrades frequently, etc. Even web hosting itself has become a service that people sign up for – in many cases setting a project up on AWS (Amazon Web Services, essentially cloud computing) is faster and easier than acquiring a real hardware server and configuring from scratch.
The rise of these third-party solutions are a testament to maturity and complexity of our digital world. Specialization makes systems more stable and dependable. Sure, any time you partner with a service there are risks. But I’ve seen so many publishing projects with social features miss their launch deadline or trash their social features before launch because they found they couldn’t get it built, that it’s hard to watch them spin their wheels over a perceived need for control. That’s a mess of work for something that isn’t the center of your business.
Publishing Focus and Third-Party Opportunity
This move to third-party social solutions should start happening with all the education, journalism, authoring platforms, writing communities and publishing projects currently in development. Although it sounds simple to just add discussion into content, the devil is in the details. Obviously the front end – the process of adding a comment – takes some work, and the estimation for that is fairly straightforward. But what about the paradigm that people use to connect? Are they following people in a Twitter paradigm, or is it a group-based, reciprocal model, like Facebook? Who can delete comments? What can you manage with your administrator dashboard? Are servers ready to scale with peak activity? What kind of stats can you get on how your audience is interacting with your content? Most of these issues don’t relate to the core business.
In the end, it comes down to the project definition. Is it a bookstore or a social network? I’m guessing nine times out of ten it’s a bookstore first, with additional social features. Focus on controlling the content and making the sale, be unique via curation and selection, and add the rest of the social features in using APIs and third party solutions. Then tweak the experience based on what those third-party services can tell you. That way you have the freedom to experiment and tweak the social options you offer your users, but still focus on your core offering. Everybody wins.
Trends of smaller, easier, and more personal content signal a shift away from read-only publishing.
Terry Jones envisons a future in which we step beyond the default of read-only publishing via traditional containers and APIs. Data itself will become social, and we'll be able to personalize arbitrarily.
In addition to Bookworm, O'Reilly Labs now includes an RDF-based API into all of O'Reilly's books: Most publishers are familiar with the ONIX standard for exchanging metadata about books among trading partners. Anyone who's actually spent time working with ONIX knows that its syntax is abstruse at best. While ONIX does use XML, there are more modern, more general, and…
The New York Times on Tuesday opened up its "Best Sellers API," offering programmatic access to best-seller data (going back to 1930!) from the Times: The Times Best Sellers API gives you quick access to current and past best-seller lists in 11 different categories, such as Hardcover Nonfiction and Paperback Mass-Market Fiction. The initial launch offers every weekly list…