In a recent post I explored why content has never had to work harder to reach audiences – how, when, and where they want to experience it.
Here I look at how publishers and content owners can get more mileage from their content by using the right architecture and tools to reach more devices.
Write once, publish anywhere
With an exploding number of formats, devices, and customer touchpoints, a key challenge, as digital strategist Nic Newman (BBC, Reuters) noted at a recent breakfast briefing with Inviqa, is figuring out how to efficiently create content that can be effortlessly repurposed for delivery to any number of devices and touchpoints.
Part of the challenge is that legacy technology stacks and content management systems (CMSes) often force organisations to operate in silos, making it difficult to seamlessly deliver content in real-time, to the right endpoints, and in the right formats.
That’s why we’re seeing the emergence of decoupled, API-driven CMSes that allow organisations to share content at scale. By storing content as structured data components, decoupled CMSes are surely the next frontier in the quest to ‘write once, publish anywhere’.
So how can content owners use this technology to open up their content to more devices?
The role of industry standards in content delivery
Structured data provides the information that allows your content to be consumed and presented in the right format on any device using common application programming interfaces (APIs), which basically allow two software applications to communicate with one another.
Thanks to the emergence of industry standards, the publishing world is moving towards one coherent way of doing things. The emergence of the REST API in particular is making it far easier to integrate systems.
A REST API uses HTTP (the set of rules for transferring files such as text and video on the internet) to handle multiple types of calls, and to return data in different formats. It’s not constrained to XML, and so can also return formats like JSON (more on that later), depending on what the client requests.
REST is used by the likes of Amazon, Google, and Twitter, and it’s a good choice for building APIs that let your audiences connect with cloud services, without your developers having to install any additional software. Simply put, the flexibility of REST allows you to build an API that meets your needs, as well as the diverse needs of your users.
How can publishers and brands structure their content to take advantage of industry standards like REST, you ask?
Start with content modelling
Taking advantage of standardisation means thinking about how to structure content in the most flexible way for devices that aren’t able to read the contents of a traditional HTML web page.
First and foremost the content owner needs a commonly understood content model that interrogates and maps the relationship between the content and how it all fits together. This is key to breaking-down content into individual components that can be managed and used in isolation.
Take a look at the following example from a Premier League football club. The organisation has many web properties, but needed common functionality and governance across them all in order to streamline and simplify how it publishes content across multiple channels.
As this example shows, a news article on a football club website could relate to a player, specific team, event, or fixture. These are all content types in their own right, and by modelling content is this way we can understand the relationship between different pieces of content, as well as ensuring that the end device or channel has access to only the parts of the data that it needs.
Getting the content model right is the first step in effective content management and delivery to multiple endpoints. It’s the foundation of everything that comes next, and needs to be defined in collaboration with stakeholders who really understand the complexity of their content alongside CMS specialists who can advise on the possible ramifications of decisions being made (from a complexity and performance perspective).
Let’s now assume we now have an airtight content model in place. How can we apply that to start using our content in different ways without any manual repurposing work?
Repurposing content across one website
Let’s take a look at a fictional food publication called Umami (disclaimer: this is a demo I’ve borrowed from Drupal 8, a CMS that supports both new and traditional modes of content management).
First up we’re going to take a quick-tour of a piece of content, from the initial subeditor’s view to the browser, pushed out to a platform for use in multiple applications within the same website.
Your content hub needs to provide a system where one piece of content is entered in a single way that can be used in multiple different ways within the same website.
The above screenshot shows what you see in a typical, modern enterprise CMS (this one happens to be Drupal 8, but I could have used any number of examples). Here we have the controls to select how a single piece of content can be used and displayed in a multitude of ways – even within a single website.
From here, one piece of content can be used in an array of formats, from a hero/banner recipe, to a list view, search result, or standalone recipe page.
This demo shows the value of breaking your content down into structured, reusable components. Our Victoria Sponge recipe, for example, is no longer treated as a webpage, but a map of information – from prep time and difficulty level, to ingredients, tagging, and images. Instead of thinking in terms of how a page looks, we need to think in terms of what makes up that content, and how parts of it can fit together or be used in isolation.
Repurposing content across different platforms
Native apps
As we touched on earlier, devices and software can struggle to interpret the meaning of your content. So how well do we think a diet tracking app would be able to understand a recipe on our recipe site? Without being able to understand the context of the recipe information, it would clearly struggle.
But by allowing the content to be presented in a machine readable format, such as JSON API, we can expose that content in an industry-standard-friendly way that can be consumed by a diet tracking app (and other things) with very little developer work required.
In this way we have the capability to see different components of content and expose these in usable and consumable formats for other devices.
It doesn’t make for a very pretty screen grab, but this image shows how your content can be presented as structured data – in other words, in the way computers want to see it. Here we can see how raw data is presented as JSON from our Umami recipes.
Now I know many publishers use white label solutions (often as a more viable alternative because of the tech stack you are running) but with our article and REST API service ready, our recipe can now be consumed – for example, by a native app (Ionic) that works on Android and iOS.
Ionic allows you to take your JSON-formatted content and insert it into completely different templates on the mobile device. This is an example of reusing content in a completely separate format, using JSON data to deliver a different thing from the same content without having to do much work in terms of building a native app.
Now let’s look at some other examples.
Amazon Echo
We know that voice-activated speakers are not a flash in the pan (to again paraphrase Nic Newman), and the sales of these devices are a testament to this.
That’s why publishers, brands, and media organisations are thinking hard about how to create content that works in a compressed, conversational, and storytelling format.
We can’t expect an Amazon Echo to read the entire contents of an article (and nor would we want to). But it might be possible for it to read a shortened summary of the piece. Again though, this requires us to present the content in a form where the device knows which parts are appropriate to use.
Check out this video where I have used structured data to make our Victoria Sponge recipe consumable by Amazon Alexa. This is a great example of the practical consumption of content data.
Internet of Things (IoT) button
Structured data can also allow us to simplify the editorial experience in other ways. For example, an IoT button such as Amazon Dash could be used to help content teams streamline their workflows. Image a scenario where our latest recipe could be published by simply pressing the IoT button.
Now imagine the benefits of this in a more time-pressured editorial environment. The pressure is on for Premier League football teams to get their content out ahead of the news sites that are competing for fan eyeballs – especially on match day when fans want the latest updates.
Now imagine the benefits if someone in the newsroom need only click an Amazon Dash button to update the scoreline on their website as a new goal is scored, or need only double-click the button to update the opponent’s score.
Given that APIs provide a means of connecting systems together to achieve different goals, these modes of alternative publishing are becoming easier.
As another example, a conversational user interface such as Slack can be used to publish an article live on a site through the use of APIs, in instances where logging in and manipulating the user interface of a CMS might be too slow.
Combined with the use of artificial intelligence, these modes of publishing have the potential to truly transform the editorial experience.
Image AI, for example (which is already available), can detect the subject and mood of your images and add tagging and taxonomy automatically. Added to your content workflow, this could mean that your content hub automatically inserts a ‘frustrated Theresa May’ image into your article.
It’s little surprise then that many major publishers are already using AI for things like improving content recommendations and automating workflows, and, together with APIs that open and connect systems, publishers increasingly have the tools to deliver more value and more personalised experiences to audiences.
What’s more, as publishers in particular move away from ad revenue models towards reader revenue programmes like subscriptions, APIs open the door new content monetisation models: from metered access, which allows API clients access to a specified number of articles, to pay-per-view, which allows API clients to trade credits for paid access, one article at a time.
Why the future is decoupled
It seems inevitable that the future of web content management and delivery is decoupled and API-driven, as publishers strive to make their content consumable in any number of ways, by any number of devices.
But as Nic Newman stressed at the Inviqa breakfast briefing, you don’t need to put your content everywhere; not all endpoints will be right for your audiences.
What’s critical though, is that media organisations move now to establish a flexible, scalable, and open-source content management system that allows them to seamlessly repurpose content for when, where, and how their audiences are demanding it.