Chapter 3 Understanding Structured Content

Freedom, flexibility, and time travel are possible for your content if you give it structure. Breaking down content into small parts makes it more usable, useful, and accessible. Don’t just make the right content, make content right.

Setting Content Free

“Prose is architecture, not interior decoration.”

—Ernest Hemingway

Content wants to be free. Like Lego. The bricks don’t change, but they can be taken apart and put back together. Add and remove bricks and reconfigure them to form a vacation house, a police station, a ship, a tree, the Millennium Falcon.

Content wants to travel through time and from place to place. It wants to be useful today as part of a website displayed in Google Chrome on a laptop and tomorrow as a response from Amazon Echo’s Alexa. And five years from now it will want to be useful as a heads-up display in a car or projected onto someone’s arm from a wristband. It can all be the same content—if you set it up properly.

Though it sounds contrary, giving content structure means giving it more flexibility and freedom. This is because you are not tied to your first idea for delivery when you create it. By planning the structure before the content itself, you can decide later how to fill it up and put it together. You can put the same content together in different ways over and over again. Just like Lego.

Before we dive into figuring out what content to create, let’s get clear on what structured content is and how it is essential to designing connected content.

What Is Structured Content?

Structured content is content that is planned, developed, and connected outside an interface so that it’s ready for any interface. It allows you to define the skeleton of your content before you create it. Breaking content into the smallest pieces possible (within reason) so that it is free to go anywhere, anytime.

As you’ll see in the modeling and designing chapters, structured content is based on concepts and resources and entities—not on web pages. This is because a web page is merely one way to deliver and display content. An app screen is another. And an Alexa skill is yet another way that content is delivered but not even displayed.

Start by considering the meaning and subject of content itself, rather than the ways in which it will be delivered. Prioritize your content resources before your interface representations. The content you create is a surrogate for something that exists outside the digital world you seek to create. An animal, a company, a country has defining characteristics that distinguish it from other examples of the same order. Structured content holds the characteristics of that thing so it can be represented in context by a website, an app, or a game. For each representation, the designer chooses which attributes to display and how they should appear.

Moving Toward Structured Content

Structure has many meanings, even within the context of content and digital products. It is a way of organizing things. It is a way of building things. It is the arrangement of parts. And we want to organize, build, and arrange content to tell stories, provide helpful information at just the right time, and open different windows into the world in which we operate.

At the heart of it, structure comes from breaking content into reusable parts and defining the rules for how those parts should connect. We’ll get into more depth about how to determine what those parts are for each type of content (Chapter 6) and how to build a system to support it (Chapter 8). But first, let’s talk about how structure gives content flexibility and sets it up for wherever it needs to go.

Gaining Flexibility

A lot of web content still gets published as standalone “pages,” created using a WYSIWYG (what you see is what you get) editor and held as an unstructured content blob in the body field of a design template. It has no inherent relationship with other pieces of content. Each blob stands alone unless manually linked together.

What we need are chunks. A chunk is a small, defined piece of content. It is pure content, devoid of any presentational styling. It’s in a malleable form that can be reused over and over with any design and in any format.

Chunks set the content free. Words, images, videos, files, and widgets are all held separately, ready to be remixed and reconnected.

Metadata can be assigned to each chunk. That data about the data establishes specific meaning. Thus, the meaning is embedded in chunks so that computers can understand what it is, what it’s about, and how it relates to other chunks. When all the chunks are put together, they provide a comprehensive understanding of a complete thing, or entity. The entity’s metadata allows computers to read and understand the content in its constituent parts or as a whole.

The structure makes machine learning and artificial intelligence possible because the computers can connect content dynamically based on the cues humans give to it. That is way easier than managing every single web page and planning for all the possible combinations users might want.

Breaking Content into Parts

Inherent structure is all around us. Look at your favorite music service. A song has a title, artist, genre, length, and year of release. A music store might add a rating and reviews. Identifying those constituent parts is the first step to organizing and arranging them.

Once you start down this road, you’ll notice structure everywhere. Heck, we can no longer visit a website without thinking about how it is structured (or not). Begin by looking at the resource, the real-world thing, rather than at a single representation on the screen. What do music lovers most want to know about a song? What do attendees need to know about a conference session? What matters most to a journalist about a building?

Rather than talking in the abstract, let’s walk through the process with some real content. Keep in mind that as we offer this example, we are making no judgment about the people who set this up originally. They are good people who did the best they could with the time, knowledge, and budget available at that time. Same as you, same as us.

Existing Web Page of Unstructured Content

FIGURE 3.1 shows an example of a web page about the Golden Gate Bridge that is unstructured and could use some help so that it can be reused in many contexts across the same website or even by other websites. After all, once the content is data with metadata attached, it can be turned into an application programming interface (API) or web service or otherwise scraped by crawlers that want to use the authoritative information about this thing. It becomes an entity.

If you looked at all 200 landmarks on the website, you’d notice the patterns and similar formatting across them all. Creating these required a human to remember and follow instructions to create consistency from one item to the next. Instead of resources, they were singular pages.

The index page that listed all the landmarks was also manually produced. When a new landmark was added, someone had to go to that page and figure out where in the list of landmarks it fit, put the cursor there, press Return, type the name of the landmark, and add a link to the landmark page.

When you are the authoritative source for civil engineering in the United States, you want to show off feats of engineering and the engineers who created them. You want to make sure historic projects are highlighted wherever they are relevant. People, organizations, and websites all over the world want this information. By turning it into structured content (Figure 3.2), you can provide authoritative and credible content without having to do extra work when the content is desired elsewhere.

Instead of redesigning the display, we created a content type for engineering projects generally. And we called it Engineering Project because the landmarks aren’t all bridges or buildings and they aren’t all historic. The Golden Gate Bridge is merely an instance of a project. While it helps to think of a few examples when deciding on the parts, don’t be limited by those examples. Consider all the instances. Engineers are a separate entity because they have completely different attributes, and we may not want to display them with Engineering Projects.

All the parts do not have to be filled in for each instance. For example, some engineering projects have a noteworthy engineer associated with them, and others do not. Some have specific street addresses (U.S. Capitol), and others are located underground (first New York City subway).

See how having the content in pieces, rather than locked in one big mass creates freedom? Like Lego bricks, the pieces can be mixed and matched to provide just the right amount of detail for each instance. Oh, and if you want to change the data within this container, you need to change it in only one place and it’s updated everywhere. Need a new field? Add it to the content type container, and every instance gets the attribute. Add a new item, and it’s added wherever you’ve specified that content type to appear. Delete an instance, and it’s removed everywhere it appeared.

Using Structured Content

Breaking content down into parts sets you up to create different representations based on use case and context. Create the structure by thinking of all the ways you want to display the resource. Use the parts for specific representations.

Arranging

Arranging each instance individually would be a lot of work. And that is what you’d have to do if you have one web page for each of those 200 projects. Even starting with an example and duplicating it 199 times presents a time and energy challenge. You would have to create each page, assign a URL, and make sure the HTML code for the page name, body paragraphs, headings, images, and links are correct and properly placed so that it will display properly. ­Making links to other pages? Highlight the right text and then go to the other page to copy the URL and paste it into the WYSIWYG editor’s box. Sure, the person creating the page is free to make choices about design, but are they qualified for that? This takes a lot of time, and human error is bound to creep in fast.

A structured content framework saves time and creates efficiencies. You arrange attributes in a template. You decide which attributes to show for a specific display, and design a display pattern that gets populated by the computer for each instance. When each project is displayed consistently and automatically, there is less room for human error.

For the Golden Gate Bridge, you might create three different templates that use various parts. The templates can have different styles applied to them. Each one uses only the attributes needed to convey a certain meaning or fulfill a user need. You might even want to bring in parts from different types of content (Figures 3.3, 3.4, and 3.5).

Many considerations come into play when deciding what content to display and how to display it. We’ll get to that in later chapters. Now you’ll know what we’re talking about when we get there (if you didn’t already).

Figure 3.3 A template for the detailed display of a project using the Engineering Project content type.

Figure 3.4 Only the Project Name, Project Type, Location, and Year Completed fields for an Engineering Project are displayed in this template for a listing of projects.

Organizing

Once content is chunked up into pieces and arranged in various ways, it needs to be connected. The website or product needs to come together as a whole. That whole needs structure too.

The organization of the content might manifest itself as a sitemap or navigation structure. Or it might be a model of the world we are working within. Each type of content has relationships with other types. An Engineering Project is planned by an Engineer. An Engineer also connects to a Conference by being a Speaker. When you zoom out from the individual connections, you see a system that is complex but orderly—just like the things they are representing, whether that is civil engineering or your organization or the IA Summit community.

Whether you are breaking down content, arranging it on a page, or organizing a system, base the structure on real-world characteristics and relationships. You don’t need to re-create things that already exist. The resources are already there; they just need new representations in a digital space.  

Writing Content Is Different Too

Authoring is different when you structure your content. The default mode for most people who create content is to think their immediate publishing needs. Adding structure to content and creating resources instead of pages requires a new approach and mindset. You might meet resistance from your authors if you tell them to fill in a bunch of fields in which they cannot change the font or color. (On the other hand, some people will be delighted to have such clear guidelines. You can’t make everyone happy!)

You can’t just plop down a new content management system in front of your content authors, most of whom may not be writers in the first place. Everyone must be educated to understand this new way of creating content. As with the rest of this process, a bit of change management needs to happen. Collaborate, communicate, and educate to gain buy-in and give your content creators a sense of ownership.

You will need to create a content production process and educate authors about how they are part of a bigger world. Just as it is no longer sustainable to have a bunch of websites with blobs of content on them, it is not feasible to create content as if it has only one purpose. Train authors about how to create content in chunks so that it makes sense in all its representations. Show them how they fit into the bigger picture and how structured content behaves so they have proper context for creating it.

Structure Everywhere

What about those pages that are not a concrete thing like an event, a person, a song, or a service? Even something that doesn’t correspond to an entity—like your privacy policy or your terms and conditions—is still a resource. It has a URL, but it is singular and doesn’t warrant its own content type. You could create an entity called Basic Page or Article that retains the flexibility of a big body field for times when there just isn’t much structure or there’s a unique type of content.

Entities with little inherent structure do exist, but they are few and far between. And they still need to be viewed and read and accessed by different screen sizes, in different browsers, and by people with differing abilities. Content must be structured in a way that still makes sense when recomposed for a small screen or read by a screen reader. That might have more to do with the underlying code than anything else, so be sure to work with your designers and engineers to make sure the content is represented accurately. Create as many separate fields as possible—even in your basic page. Those fields may need to travel too.

Go Forth and Create Structure

So far, we’ve outlined a process that makes your content better, longer lasting, and usable everywhere. To be successful, you need to shift your thinking from “What pages go on my website?” to “How do I structure the content about the world I’m representing with my digital product?”

You could conceivably chunk every bit and byte of content into the smallest particles that humans could imagine. The computer overlords would love it. But we live in the real world, where everything is imperfect and computers haven’t quite taken over yet. To help them along, we need to create content with structure and purpose to be ready for machine learning and algorithmic processing. Don’t think it won’t happen to your content. Expect it and anticipate it.

Structured content is a lens into content strategy. Applying structure up front helps you get the right information to the right people at the right time—­without re-creating it time and again. This is the basis of content strategy, which advocates a content-first approach to projects. Not just writing the right content, but creating it the right way to be useful and usable.