About Michael Andrews

We’re entering a new era of digital transformation: every product and service will become connected, coordinated, and measured. How can publishers prepare content that’s ready for anything? The stock answer over the past decade has been to structure content. This advice — structuring content — turns out to be inadequate. Disruptive changes underway have overtaken current best practices for making content future-ready. The future of content is no longer about different formats and channels. The future of content is about different modes of interaction. To address this emerging reality, content strategy needs a new set of best practices centered on the strategic use of metadata. Metadata enables content to be multimodal.

What does the Future of Content look like?

For many years, content strategists have discussed how people need their content in terms of making it available in any format, at any time, through any channel that the user wanted. For a while, the format-shifting, time-shifting, and channel-shifting seemed like it could be managed. Thoughtful experts advocated ideas such as single-sourcing and COPE (create once, publish everywhere) which seemed to provide a solution to the proliferation of devices. And it did, for a while. But what these approaches didn’t anticipate was a new paradigm. Single-sourcing and COPE assume all content will be delivered to a screen (or its physical facsimile, paper). Single-sourcing and COPE didn’t anticipate screenless content.

Let’s imagine how people will use content in the very near future — perhaps two or three years from now. I’ll use the classic example of managed content: a recipe. Recipes are structured content, and provide opportunities to search according to different dimensions. But nearly everyone still imagines recipes as content that people need to read. That assumption no longer is valid.

Cake made by Meredith via Flickr (CC BY-SA 2.0)

In the future, you may want to bake a cake, but you might approach the task a bit differently. Cake baking has always been a mixture of high-touch craft and low-touch processes. Some aspects of cake baking require the human touch to deliver the best results, while other steps can be turned over to machines.

Your future kitchen is not much different, except that you have a speaker/screen device similar to the new Amazon Echo Show, and also a smart oven that’s connected to the Internet of Things in the cloud.

You ask the voice assistant to find an appropriate cake recipe based on wishes you express. The assistant provides a recipe, which has a choice on how to prepare the cake. You have a dialog with the voice assistant about your preferences. You can either use a mixer, or hand mix the batter. You prefer hand mixing, since this ensures you don’t over-beat the eggs, and keep the cake light. The recipe is read aloud, and the voice assistant asks if you’d like to view a video about how to hand-beat the batter. You can ask clarifying questions. As the interaction progresses, the recipe sends a message to the smart oven to tell it to preheat, and provides the appropriate temperature. There is no need for the cook to worry about when to start preheating the oven and what temperature to set: the recipe can provide that information directly to the oven. The cake batter is placed in the ready oven, and is cooked until the oven alerts you that the cake is ready. The readiness is not simply a function of elapse time, but is based on sensors detecting moisture and heat. When the cake is baked, it’s time to return giving it the human touch. You get instructions from the voice/screen device on how to decorate it. You can ask questions to get more ideas, and tips on how to execute the perfect finishing touches. Voila.

Baking a cake provides a perfect example of what is known in human-computer interaction as a multimodal activity. People seamlessly move between different digital and physical devices. Some of these are connected to the cloud, and some things are ordinary physical objects. The essential feature of multimodal interaction is that people aren’t tied to a specific screen, even if it is a highly mobile and portable one. Content flows to where it is needed, when it is needed.

The Three Interfaces

Our cake baking example illustrates three different interfaces (modes) for exchanging content:

The screen interface, which SHOWS content and relies on the EYES
The conversational interface, which TELLS and LISTENS, and relies on the EARS and VOICE
The machine interface, which processes INSTRUCTIONS and ALERTS, and relies on CODE.

The scenario presented is almost certain to materialize. There are no technical or cost impediments. Both voice interaction and smart, cloud-connected appliances are moving into the mainstream. Every major player in the world of technology is racing to provide this future to consumers. Conversational UX is an emerging discipline, as is ambient computing that embeds human-machine interactions in the physical world. The only uncertainty is whether content will be ready to support these scenarios.

The Inadequacy of Screen-based Paradigms

These are not the only modes that could become important in the future: gestures, projection-based augmented reality (layering digital content over physical items), and sensor-based interactions could become more common. Screen reading and viewing will no longer be the only way people use content. And machines of all kinds will need access to the content as well.

Publishers, anchored in a screen-based paradigm, are unprepared for the tsunami ahead. Modularizing content is not enough. Publishers can’t simply write once, and publish everywhere. Modular content isn’t format-free. That’s because different modes require content in different ways. Modes aren’t just another channel. They are fundamentally different.

Simply creating chunks or modules of content doesn’t work when providing content to platforms that aren’t screens:

Pre-written chunks of content are not suited to conversational dialogs that are spontaneous and need to adapt. Natural language processing technology is needed.
Written chunks of content aren’t suited to machine-to-machine communication, such as having a recipe tell an oven when to start. Machines need more discrete information, and more explicit instructions.

Screen-based paradigms presume that chunks of content would be pushed to audiences. In the screen world, clicking and tapping are annoyances, so the strategy has been to assemble the right content at delivery. Structured content based on chunks or modules was never designed for rapid iterations of give and take.

Metadata Provides the Solution for Multimodal Content

Instead of chunks of content, platforms need metadata that explains the essence of the content. The metadata allows each platform to understand what it needs to know, and utilize the essential information to interact with the user and other devices. Machines listen to metadata in the content. The metadata allows the voice interface and oven to communicate with the user.

These are early days for multimodal content, but the outlines of standards are already in evidence (See my book, Metadata Basics for Web Content, for a discussion of standards). To return to our example, recipes published on the web are already well described with metadata. The earliest web standard for metadata, microformats, provided a schema for recipes, and schema.org, today’s popular metadata standard, provides a robust set of properties to express recipes. Already millions of online recipes are described with metadata standards, so the basic content is already in place.

The extra bits needed to allow machines to act on recipe metadata are now emerging. Schema.org provides a basic set of actions that could be extended to accommodate IoT actions (such as Bake). And schema.org is also establishing a HowTo entity that can specify more specific instructions relating to a recipe, that would allow appliances to act on the instructions.

Metadata doesn’t eliminate the need for written text or video content. Metadata makes such content more easily discoverable. One can ask Alexa, Siri, or Google to find a recipe for a dish, and have them read aloud or play the recipe. But what’s needed is the ability to transform traditional stand-alone content such as articles or videos into content that’s connected and digitally native. Metadata can liberate the content from being a one-way form of communication, and transform it into being a genuine interaction. Content needs to accommodate dialog. People and machines need to be able to talk back to the content, and the content needs to provide an answer that makes sense for the context. When the oven says the cake is ready, the recipe needs to tell the cook what to do next. Metadata allows that seamless interaction between oven, voice assistant and user to happen.

Future-ready content needs to be agnostic about how it will be used. Metadata makes that future possible. It’s time for content strategists to develop comprehensive metadata requirements for their content, and have a metadata strategy that can support their content strategy in the future. Digital transformation is coming to web content. Be prepared.

— Michael Andrews

Everyone involved with publishing web content, whether a writer, designer, or developer, should understand how metadata can describe content. Unfortunately, web metadata has a reputation, not entirely undeserved, for being a beast to understand. My book, Metadata Basics for Web Content, explains the core concepts of metadata. This post is for those ready to take the next step: to understand how a metadata standard relates to their specific content.

Visualizing Metadata

How can web teams make sense of voluminous and complex metadata documentation? Documentation about web metadata is generally written from a developer perspective, and can be hard for non-techies to comprehend. When relying on detailed documentation, it can be difficult for the entire web team to have a shared understanding of what metadata is available. Without such a shared understanding, teams can’t have a meaningful discussion of what metadata to use in their content, and how to take advantage of it to support their content goals.

The good news is that metadata can be visualized. I want to show how anyone can do this, with specific reference to schema.org, the most important web metadata standard today. The technique can be useful not only for content and design team members who lack a technical background, but also for developers.

Everyone who works with a complex metadata standard such as schema.org faces common challenges:

A large and growing volume of entities and properties to be aware of
Cases where entities and properties sometimes have overlapping roles that may not be immediately apparent
Terminology that can be misunderstood unless the context is comprehended correctly
The prevalence of many horizontal linkages between entities and properties, making navigation through documentation a pogo-like experience.

First, team members need to understand what kinds of things associated with their content can be described by a metadata standard. Things mentioned in content are called entities. Entities have properties. Properties describe values, or they express the relationship of one entity to another.

Entities are classified according to types, which range from general to specific. Entity types form a hierarchy that can be expressed as a tree. All entities derive from the parent entity, called Thing. Currently, schema.org has over 600 entity types. Dan Brickley, an engineer at Google who is instrumental in the development of schema.org, has helpfully developed an interactive visualization in D3 (a Javascript library for data visualization), presented as a radial tree, which shows the distribution of entity types within schema.org. The tool is a helpful way to explore the scope of entities addressed, and the different levels of granularity available.

Screenshot of entity tree, available at http://bl.ocks.org/danbri/raw/1c121ea8bd2189cf411c/

D3 is a great visualization library, but it requires both knowledge and time to code. For our second kind of visualization, we’ll rely on a much simpler tool.

Graphs of Linked Data

Web metadata can connect or link different items of information together, forming a graph of knowledge. Graphs are ideal to visualize. By visualizing this structure, content teams can see how entities have properties that relate to other entities, or that have different kinds of values. This kind of visualization is known as a concept map.

Let’s visualize a common topic for web content: product information. Many things can be said about a product: who is it from, what is like, and how much it costs. I’ve created the below graph using an affordable and easy-to-use concept mapping app called Conceptorium (though other graphic tools can be used). Working from the schema.org documentation for products, I’ve identified some common properties and relationships for products. Entities (things described with metadata) are in green boxes, while literal values (data you might see about them) are in salmon colored boxes. Properties (attributes or qualities of things) are represented by lines with arrows, with the name of the property next to the line.

Concept map of schema.org entities and properties related to products

The graph illustrates some key issues in schema.org that web teams need to understand:

The boundary between different entity types that address similar properties
The difference between different instances of the same entity type
The directional relationships of properties.

Entity Boundaries

Concept maps help us see the boundaries between related entity types. A product, shown in the center of our graph, has various properties, such as a name, a color, and an average user rating (AggregateRating). But when the product is offered for sale, properties associated with the conditions of sale need to be expressed through the Offer entity. So in schema.org, we can see that products don’t have prices or warranties; offers have prices or warranties. Schema.org allows publishers to express an offer without providing granular details about a product. Publishers can note the name and product code (referred to as gtin14) in the offer together with the price, and not need to use the Product entity type at all. The Offer and Product entity types both use the name and product code (gtin14) properties. So when discussing a product, the team needs to decide if the content is mostly about the terms of sale (the Offer), or about the features of the product (the Product), or both.

Instances and Entity Types

Concept maps help us distinguish different instances of entities, as well as cases where instances are performing different roles. From the graph, we can see that a product can be related to other products. This can be hard to grasp in the documentation, where an entity type is presented as both the subject and the object of various properties. Graphs can show how there can be different product instances that may have different values for the same properties (e.g., all products have a name, but each product has a different name). In our example, we can see that on product at the bottom right is a competitive product to the product in the center. We can compare the average rating of the competitor product with the average ratings of the main product. We can also see another related product, which is an accessory for the main product. This relationship can help identify products to display as complements.

An entity type provides a list of properties available to describe something. Web content may discuss numerous, related things that all belong to the same entity type. In our example, we see several instances of the Organization entity type. In one case, an organization owns a product (perhaps a tractor). In another case, the Organization is a seller. In a third case, the Organization is a manufacturer of the product. Organizations can have different roles relating to an entity.

Content teams need to identify in their metadata which Organizations are responsible for which role. Is the seller the manufacturer of the product, or are two different Organizations involved? Our example illustrates how a single Person can be both an owner and a seller of a Product.

What Properties Mean

Concept maps can help web teams see what properties really represent. Each line with an arrow has a label, which is the name of the property associated with an entity type. Properties have a direction, indicated by the arrow. The names of properties don’t always directly translate into an English verb, even when they at first appear to. For example, in English, Product > manufacturer > Organization doesn’t make much sense. The product doesn’t make the organization, but rather the organization manufactures the product. It’s important to pay attention to the direction of a property: what entity type is expected — especially when these relationships seem inverted to how we think about them normally.

Many properties are adjectives or even nouns, and need helper verbs such as “has” to make sense. If the property describes another entity, then that entity can involve many more properties to describe additional dimensions of that entity. So we might say that “a Product has a manufacturer which is an Organization (having a name, address, etc.)” That’s not very elegant in English, but the diagram keeps the focus on the nature of the relationships described.

Broader Benefits of Concept Mapping for Content Strategy

So far, we’ve discussed how concept maps can help web teams understand what the metadata means, and how they need to organize their metadata descriptions. Concept maps can also help web teams plan their content. Teams can use maps to decide what content to present to audiences, and even what content to create that audiences may be interested in.

Content Planning

Jarno van Driel, a Dutch SEO expert, notes that many publishers treat schema.org as “an afterthought.” Instead, Jarno argues, publishers should consult the properties available in schema.org to plan their content. Schema.org is a collective project, where different contributors identify properties relating to entities they would like to mention that they feel would be of interest to audiences. Schema.org can be thought of as a blueprint for information you can provide audiences about different things you publish. While our example concept map for product properties is simplified to conserve space, a more complete map would show many more properties, some of which you might decide to address in your content. For example, audiences might want to know about the material, the width, or the weight of the product — properties available in schema.org that publishers may not have considered including in their content.

Content Design and Interaction Design

Concept maps can also reveal relationships between different levels of information that publishers can present. Consider how this information is displayed on the screen. Audiences may want to compare different values. They may want to know all the values for a specific property (such as all the colors available), or they want to compare the values for a property of two different instances (average rating of two different products).

Concept maps can reveal qualifications about the content (e.g., an Offer may be qualified by an area served). Values (shown in salmon) can be sorted and ranked. Concept maps also help web teams decide on the right level of detail to present. Do they want to show average ratings for a specific product, or a brand overall? By consulting the map, they can consider what data is available, and what data would be most useful to audiences.

Concept map app shows columns of entities and values, which allow exploration of relationships

Conclusion

Creating a concept map requires effort, but is rewarding. It requires you to compare the specification of the standard with your representation of it, to check that relationships are known and understood correctly. It allows you to see some characteristics, such as properties used by more than one entity. It can help content teams see the bigger picture of what’s available in schema.org to describe their content, so that the team can collectively agree to metadata requirements relating to their web content. If you want to understand schema.org more completely, to know how it relates to the content you publish, creating a concept map is a good place to start.

— Michael Andrews