Accueil / Blog / Content professionals, it’s time to welcome in the unknown consumer

Content professionals, it’s time to welcome in the unknown consumer

unknown consumer
Not so long ago, content professionals only had to contend with the Browser Wars, and that was painful enough. Our main concern was figuring out which browsers supported which types of Markup, CSS, and JavaScript, and to what standardize on. Consistency was the aim of the game.

But content professionals today are operating in a dramatically different place. Since 2007, we've been living in a world of smart phones and tablets where it’s expected that everything we build on the web will work effectively on every variation of these devices. In 2007, it took the iPhone to move us into the next chapter. In 2017, we’re seeing a whole range of devices that will usher us into the next. We’re about to hit a new phase of web development where content takes precedence and the devices consuming it are unknown to us.

The rise of the unknown consumer

Today, content professionals must accommodate an explosion of new distribution platforms. Previously, voice user interfaces like Siri on iOS were proprietary and therefore inaccessible to web and application developers. Now, devices like the Amazon Echo and Google Home offer a far more accessible APIs for content consumption, we’ll undoubtedly see a massive uptake in content-driven services in 2017.

These devices are not the only new destinations for our content. There are a huge number of smart devices that are not yet accounted for. I refer to these new platforms collectively as ‘the unknown consumer’. Many of these new and emerging internet-connected devices can be content consumers. We can't predict everything they’ll be capable of, or what they can do with our content – and there's no way we can ever know because the possibilities are endless.

What does the future hold?

We’ve seen this shift coming for a while now. Drupal project lead and founder Dries has posted about it in depth, and Acquia Labs is focusing exclusively on creating new distribution platforms for these unknown consumers.

When pondering this topic, I like to explore how application programming interfaces (API) are creating new opportunities for content professionals, and how any organizations can take advantage of them.

API lessons from The Economist

At a recent media and publishing event, our peers at The Economist shared some insight into vast array of platforms they can now serve content to.


Compared to just a few years ago, this landscape now requires the capability to deliver content in raw forms. Using structured data, The Economist ensures content is customizable for every available platform.

Content is exposed to different media platforms and services through an application programming interface (API) layer in the content platform. This layer is responsible for ensuring content is optimized for the design and presentation that suits the platform being targeted.

Exposing your content

At Inviqa, we believe all technology decisions should be centered around the business goal or objective you’re trying to address. In this scenario, that objective (albeit very wide-ranging) could be the following:

‘I need to be able to serve content now and in the future to devices whose capabilities and intent may be unknown to me – without relinquishing publishing control’.

It’s important to note that many of tomorrow’s content-consuming devices won’t be able to read the contents of a typical web page.

In the traditional model, we expose our content as HTML with the assumption that a web browser will consume the content, making certain decisions about layout and presentation depending on the capabilities of the rendering engine. However when thinking about the content opportunities of tomorrow, we’re not concerned with layout – but instead pure, structured data.

Designing an API

The design of an API for the purposes of exposing our content is very much like designing the content model. We need to provide methods for systems to quickly and efficiently search for content and then to extract the specific parts of the content model they require.

Since we are not necessarily expecting to be in communication with those who are using our content, it is important to provide clear documentation so that anything we do provide is clear and concise.

One of my favorite 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.

Once the Blueprint is agreed, we can build the API in our preferred CMS making sure it adheres to the contract the API implies.

We also need to respect that other people are building a dependency on our content and therefore we must be careful about versioning of the API in the future to ensure backwards compatibility.

Why Drupal is API-first

Drupal 8 has a core initiative to make it API-first. As Dries points out, this does not mean Drupal becomes API-only. With community modules like JSON API it’s even easier to expose Drupal’s content model to unknown consumers in an industry standard format.

Using Drupal allows us to model content effectively and therefore refine the editor experience for both headless and traditional use cases simultaneously.

Preparing for the future and creating a legacy

This post has been concerned with dealing with the unknown, but it’s also important that we are responsible with our content and the parts of the system that are under our control.

In the space of the last two decades we have made huge number of data storage formats obsolete. 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.
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.

Ajouter un commentaire

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • Pour publier des morceaux de code, entourez-les avec les balises <code>...</code>. Pour du PHP, utilisez. <?php ... ?>, ce qui va colorier le code en fonction de sa syntaxe.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Les lignes et les paragraphes vont à la ligne automatiquement.
By submitting this form, you accept the Mollom privacy policy.