Welcoming in the unknown consumer
In previous posts in this series we looked at how to approach content modelling for unknown content-consuming devices, and we explored some practical tips for implementing a content model using a content management system.
Here we’ll look at how we can open up your content to the world, inviting your unknown audiences to start using it for exciting new use cases.
Expose your content
The premise we’re exploring in this blog series is that there will be (and may already be) new devices that consume your content in ways you don’t know about – for use cases that are still being conceived.
In the traditional content model, you expose your content as HTML with the assumption that it will be consumed by a web browser. You make certain decisions about layout and presentation depending on the capabilities of the rendering engine.
But in the new scenario we are discussing, we are not concerned with layout, but pure, structured data, because many of these new devices won’t be able to read the type of data we traditionally store in a content management system (CMS).
The preferred approach is to expose an application programming interface (API) that can be queried. The dictionary definition of API feels a little outdated for the purposes of today but the principles are exactly the same as they have been for many years:
A set of functions and procedures that allow the creation of applications which access the features or data of an operating system, application, or other service.
Design an API
Designing an API for the purposes of exposing your content is very much like designing the content model in the first place. You need to provide methods for systems to quickly and efficiently search for content, and then to extract the specific parts of the content model required.
Since you won’t necessarily be in communication with those who are using your content, it’s important to provide clear documentation to them, so that anything you do provide is clear and concise.
One of my favourite tools for this process is Apiary which allows you to create an API model in a prototype form and to provide mock responses for testing. This can become your blueprint and documentation so that anyone who wants to make use of your content is fully aware of what the capabilities are.
Apiary believes an API is only as good as its documentation
Once the blueprint is agreed, you can build the API in your preferred CMS making sure it adheres to the contract the API implies.
You also need to respect that other people are building a dependency on your content, and therefore you should be careful about versioning of the API in the future to ensure backwards compatibility.
Use new business models
When thinking of a traditional website there are a number of tried-and-tested methods of monetising content. That might be a paywall block or an alternative, free version of the article.
An API can provide a controlled way to meter content
An API approach provides you with a more controlled way of metering your content. A few examples might be:
- Metered access: allowing API clients to access a certain number of articles, or have full access for a specific period of time.
- Differential access: allowing API clients to access some fields in the content model and others at a premium access level – free teasers, for example, with full content at a premium.
- Pay per view: allowing API clients to trade credits for paid access, one article at a time.
Being flexible with the content models you provide will encourage the development of consumers for your content. With growing pressure on the advertising revenue associated with content, providing value via enhanced, ‘naked’ content could be an effective and alternative business model. It also allows you to try different models with less complexity than you might face with a traditional website.
Create a content legacy
The posts in this series have been concerned with dealing with the unknown – but it’s also important that you are responsible with your content and the parts of the system that are under your control.
Preparing for new devices and formats helps you create a legacy of content
In the space of the last two decades we have created and made obsolete a huge number of data storage formats. A recent office move uncovered some very short-lived Jazz drives from which it’s very unlikely we’ll recover data. Physical formats are one thing, but data formats are also a concern. Can we still read a graphics file from an obsolete application last used in 2003?
Even worse is the current tendency to replatform and rebuild your web presence every few years. In my experience, websites have a lifespan of 2-5 years due to changes in technique, design, and technology.
However the content we produce should last forever. We should not be relying on the heroic efforts of the Internet Archive to preserve the content legacy of the 21st century. It’s far too easy to consider content as disposable and we will suddenly find a huge gap in our collective knowledge that is decades-wide.
We can’t predict the future, but we can prepare for it. By preserving your content in a pure form – that can be accessed easily by future consumers – you’re creating a legacy of content that can be presented in whatever formats the future holds.