Chapter 6 Translating to a Content Model

Now that your team has shown off how much they know about their area of expertise and created a domain model, they’ll be excited about making it all come to life. Have patience! Some stakeholders—and even some of your team—may want to jump ahead. They’re going to start talking about what will go on the website or how to build or design the product. But you aren’t there yet. You still aren’t talking about the CMS or any interface. You’ve got a little more work to do first.

Content vs. Expression

The domain model provides the context. It grounds you in the real world, where users live and businesses operate. Content is the expression of paths through and between the objects of your domain.

You might think of the domain object as an atom. It’s got a bunch of protons, electrons, and neutrons flying around inside it. It’s time to look in the microscope and discover what those are. It’s time for some structure. Enter the content model.

A content model represents the content and its relationships. It zooms in and provides structure to the objects that were mapped in the domain model. A content type is a reusable container for managing content by common structure and purpose. A content model is a visual representation of the content types in a subject area, their properties, and the relationships between them.

A content model is an evolution of a domain model and generally inherits the object names, providing a direct link between the models.

What we’re suggesting might be a bit different from what you have seen in other content models, which usually are limited to a single website or product. We stick to the “boxes and arrows” approach for our content model. Keeping it in a simple visual format early allows non-technical stakeholders to stay involved at a point when their expertise is valuable—even essential. Don’t worry! We’ll get to a spreadsheet for each interface eventually. (How could we call ourselves content strategists otherwise?)

The content model should include content types for the specific area of your domain that matters to your business. Because the model focuses specifically on your business and audience, you might say that it focuses on the brand. For example, focus on the IA Summit specifically, not just any old conference. Or focus on Disney theme parks, not other theme parks, like Legoland or ­Dollywood. Be sure to keep the entire business in mind rather than a particular product. Staying away from a specific product will make your content portable and long-lasting.

From Domain Model to Content Model

Getting from domain model to content model involves collaboration to harness the collective wisdom of your experts and users. Get ready for more sticky-note, whiteboard, brain-dump fun! Harry Potter fans might picture Dumbledore extracting his thoughts into the Pensieve for Harry to view. That’s kind of what we’re doing: getting thoughts from someone else’s head (your experts and your team) and putting them into a form that others (your audience) can make sense of and use for their own benefit.

Where a domain model maps the world, a content model focuses on the structure and content you’ll actually publish. Pick the objects and relationships from the domain model that make sense for your organization to address. You are part of a wider world. Claim your spot in it. The objects you expose from your domain model will depend on how you fit into the domain itself. If you modeled the right domain, though, you should be covering most of the objects in your content model.

When working on the IA Summit, we could have created a domain model that would be reusable for conferences generally or for ASIS&T conferences (the Association for Science Information & Technology, which runs the IA Summit), but we were concerned only with the IA Summit. We also could have considered the 2015 IA Summit specifically rather than all the events before and after. But we wanted to span the years and have a consistent and extensible repository for all the events. If we had gone with the more general Conferences domain model, we still could have limited our content model to the IA Summit. You’re constantly evolving and making decisions about what spot to claim within the wider universe of your subject area.

Deciding What to Keep in the Content Model

The first step is to put your domain model back on the board. You’ll likely have some objects you might not want to include in the content model. Maybe they aren’t part of your core business. Maybe you cannot speak to some concepts with authority. Or you might not have content for some of the objects yet. You can hide concepts from the domain model that you are not going to include in your content model. Remove, cross out, gray out, or otherwise hide the concepts and relationships that you will not be using.

Think twice about removing a connecting object. The lines are just as important as the boxes they connect, so pay attention to what happens to the lines when you hide an object. Do relationships change? If so, do the new ones still make sense? If they do, proceed. If not, document the decision that the object is needed to keep relationships intact.

Take the example of Live Music (Figure 6.1). A ticket seller probably doesn’t need to worry about the Setlist or Song domain objects. It is tempting to remove Lineup. But Lineup connects Act and Performer. If you remove Lineup, you lose the ability to link an individual (Performer) who sometimes tours with a band (an Act). We see this often. A lead singer who normally tours with a band is on a solo tour. Or someone who is normally a solo act tours with a band—or put together a different band. Customers might search only for the most well-known part of that relationship. Keeping Lineup allows the connection to happen. You wouldn’t want someone missing out because they searched for Neil Young, who might be touring with Crosby, Stills, and Nash this year. Or missing out on the Eddie Vedder ukulele tour because they searched for Pearl Jam. Or missing Elvis Costello, who is sometimes by himself, sometimes with the Attractions, and other times with the Imposters—three different acts.

Collaborating to Make Better Choices

Because you’ve got everyone in your band back together, this is the time for your team to have conversations about what this model means for your organization. Any particular department or area may be responsible for only a subsection of the model. In that case, pay attention to the relationships and make sure all departments work together so that the content joins up. It does not matter who within the organization is responsible for concepts or whether some concepts might span many departments. Collaboration and high-level buy-in are essential to maintain objectivity and capture as much information as you can about your world.

In fact, this is part of the beauty of starting with the domain and then building a content model without worrying about an interface or product: You help create stakeholder alignment early. Everyone involved sees the connections and can account for them when it is time to create content. The benefits are potentially enormous. Less duplicate content, easier content curation, and more consistent customer experiences could be boons for your bottom line. But we’re getting ahead of ourselves.

From Objects to Content Types

At this point along the journey from abstract to specific, domain-model objects become content types with assigned attributes. Sometimes there isn’t a straight line from a domain object (a real-world thing defined in the domain model) to a content type (a reusable container that describes the consistent form of similar content). You might find that what looked like a single concept is really two or three content types or that some objects get subsumed by others. New content types will emerge as objects come into focus. There is no “correct” answer. It’s kind of a Goldilocks dilemma: finding just the right number of content types, not too many and not too few. You want as many as are useful for your team. You don’t have to get it right the first time, either. You can add, remove, or change them at any time. Focus on what content you intend to support, and you’ll keep going in the right direction.

Making Good Content Types

When you know which parts of the domain model you are going to include as content types, you can start describing them. While you can think about how this will play out in the CMS, do your best to keep your thinking high level and not specific to any system.

In the wider world, a Person has many more attributes than are shown here (Figure 6.2). But in our IA Summit domain, we limited the set of attributes to what mattered to us. Does this include more or less than you thought? In our case, we thought outside the box of a single website but not so far that we included more than what conference attendees look for. We are thinking of a Person as a resource, a thing that can be used in many contexts as it relates to a conference—or even to many conferences. This broadens our perspective from thinking only about a website—or even about a specific instance of a conference. We wanted all these people to write blog posts, to show up on Lanyrd.com (a social conference directory), and to play multiple roles from year to year.

Considering the entire business case becomes even more important if you produce many conferences. You could reuse Person across the conferences and years. Carrie has participated in several of one organization’s conferences over many years, as a participant and as a speaker. She’s always the same person for each of those conferences, even when she’s changed her name and title. Shouldn’t the organization be able to assign her to any conference for any year rather than re-collect and re-enter all her information each time for each conference website? Name changes, job changes, photos, and bios could be updated once and spread across the instances.

Or maybe you don’t want that information updated everywhere. That is a choice to make and a decision point. Modeling exposes complexity early in a project. Have the discussion now about what to do. In this case, ask

• Do we want the biographical information (title, company, biography text) to be tied to the person or to the event?

• Do we want each event to reflect the most current information or to reflect what was accurate at the time of the event?

Maybe it is important that a speaker’s title and company for the 2014 event be whatever it was in 2014 while the information for the 2017 event is whatever was current in 2017. Now is the time to make this decision. It affects your model, and it will affect how you build your system. This and other decisions have to do with business rules rather than engineering. Don’t leave it for engineers to decide. You will save untold hours of work later by dealing with the complexity up front.

Defining Attributes

Everything has attributes. A car could be a red SUV with seating for five, a moonroof, a 4-cylinder/2.5L engine, a black interior, and a Bose stereo system. Or it could be a blue coupe with seating for four, a 4-cylinder/1.6L engine, a tan interior, and a Harman Kardon stereo system. When you buy a car, you care a lot about its attributes even if you think of them as “features” or “specifications.”

An attribute is a characteristic or quality of an object. Defining the attributes of your content types is the essence of the content model. Which ones you care about depend on your situation. When you’re car shopping, price is probably a top attribute, as are color and reliability rating. If your family is growing, seating capacity and safety rating become important. When you walk up to a new car in a dealer’s parking lot, you see a piece of paper in the window with these things and more listed. Open Consumer Reports and you’ll see some of the same attributes, plus more.

The British card game Top Trumps is based on comparing attributes of similar things. The topics are very wide ranging, from Sports Cars to Creatures of the Deep, and they come in special editions like Queen’s Jubilee Celebration and 2012 Summer Olympics. To play, you choose from one of your cards an attribute that you think is better than the other players’ attributes, and you call out the attribute and its value. Whichever player has the best value for that attribute gets to keep the cards. Play continues until one player has all the cards. Oh, the hours of entertainment people get from comparing things!

But we digress. The point is that the manufacturer has made a game from comparing four or five attributes of things. And it’s a perfect illustration for a content type. The Sports Cars deck (Figure 6.3) describes the car in two sentences and breaks out certain attributes:

• Top speed (MPH)

• Engine size

• Cool factor

• Innovation

• Year launched

Of course, there are many more attributes for each car, but these five were the ones the creators chose as most interesting to game players. In a roomful of automotive engineers, the list of attributes would expand greatly. If we were lucky enough to get an audience with John Lasseter and his Cars animators, we’d have a different set.

The context for defining attributes matters. You determined your context when you decided which subject domain to model. As you approach each content type, think about what attributes matter. Go to the edges of the world you know and maybe a step or two beyond. Think about how you might connect to other domains and which attributes would be needed to connect with them. You want to be prepared for the future. It is better to have too many attributes than not enough. If we thought we might want to have our IA Summit Person link up with the registration system, we would have included address, phone number, and email address as attributes so that we would be ready to make the connection.

With your group of experts and stakeholders, expand your domain object boxes to content type cards. You are getting in deep now. When the discussion moves from concept definitions to attributes, you start finding gaps, redundancies, and objects that don’t need to be part of the content model. You may find that what you thought was a separate concept is really an attribute of something else.

In our IA Summit domain model, we decided that Hotel, while certainly an object and an entity in general, was not something that we needed to create content for or needed a URL specific to the IA Summit. For our purposes, it would be enough to include hotel information in the Event content type and link to the hotel’s reservation system in the content itself.

Combining Multiple Objects into
a Single Content Type

When we considered Session, Session Format, Topic, and Track objects, we spent time considering whether we needed entities for each of them (Figure 6.4).

Figure 6.5 Session content type.

After discussing these questions as a team, we decided that we would not use Session Format and Topic on their own. So we simplified our model by making them attributes of Session, not entities in and of themselves. As for Track, we decided it was not applicable enough to become part of the content model, so we excluded it. Four objects became one content type named Session (Figure 6.5).

We could have decided to keep Topic separate as an entity. But we envisioned Topic to be displayed only in the context of a session, so we didn’t need it to be anything more than an attribute. If we wanted to have a topic page that would show a collection of all the content tagged with that topic (thus being a resource with a URL), we would have made a Topic content type.

Similarly, we considered Location. We had defined it as “Place the event is held. Different city each year.” Did that need to be a content type? As defined, it would have only a single attribute and be related to an Event in a one-to-one relationship (so far, the Event has not been in the same city twice, and we did not anticipate that changing) (Figure 6.6). Many of the other objects contained a specific aspect of a location too. The concept Location had been too explicitly defined. Instead, several objects included some sort of location as an attribute (Figures 6.7 and 6.8).

As you can see, a lot of detailed thinking is involved in this step. You need to retain the context of your domain model while thinking specifically about how you will apply it in order to determine the attributes. Don’t worry if your domain model feels simplistic and out of date now. You can always update it based on this new information.

Figure 6.6 Each Session is held in a City and a State (in the U.S.) or Province (in Canada)..

Figure 6.7 There are many Location attributes for a Venue, not just city and state, as with Event.

Figure 6.8 For a Session, the overall Location is linked through the Venue and also has a specific Room location.

Figure 6.9 The Blog Post content type we added to the IA Summit model after the domain-model objects were turned into content types.

Adding to the Model

In our initial IA Summit model, we focused first on getting everything just right for the complicated content types, like Session and Person. Eventually, we realized we needed to model a Blog Post too. It could be considered an object (person – writes – post), and it had critical relationships with other content types in the model. A Blog Post (Figure 6.9) needed an author, which was really a Person, so was that another Role? And would it be related to the Event or the Brand? The decisions were documented in the content type.

Some things that aren’t specific content types or objects will show up on your website or in your product. These will not be included in the model. They are things like the About page or your code of conduct. This is not the time to think about the entire inventory of content you’ll end up with. It is the time to consider how to model the reality of the world and what things and connections your users want. Don’t drive yourself crazy trying to get everything in the model. It will continue to evolve, and you can always come back and update it later.

Reconnecting to Form the Content Model

You dissected everything to create your content types. You incorporated multiple objects into single content types, separated other objects into multiple content types, and added any new ones you discovered. Now you need to put it all back together again.

Relationships can be much more specific in the content model than in the domain model. Content types can be connected by linking attributes themselves rather than generally between the objects. Some attributes are entities themselves, and thus there are natural relationships between some content types. That is sometimes called an entity reference, because you are referring to another entity as an attribute, which creates a relationship.

Figure 6.10 Final IA Summit content model.

Whether consciously decided or not, some of the content types’ attributes are the same. And thus, the two content types become inherently connected. One example in our IA Summit model (Figure 6.10) is Topic, which is an attribute in both Session and Blog Post. Although we would not necessarily have connected those two content types, because they have that attribute in common, we can form a relationship that could enhance publishing in ways that will allow future Summit co-chairs to curate content in many ways.

Adding the relationships provides a richer palette with which to work and may even cause you to add some attributes. This is because you get granular enough that you discover new possibilities. Check your model by considering the original relationship from the domain model. Have you created attributes that allow the connection? Has the connection changed deliberately?

From our original domain model, with 12 objects, we ended up with seven content types (including the new one we added). We described the decisions around this evolution throughout this chapter. In summary, this is what happened to the six objects that didn’t make the cut as content types:

• Brand, having just a single instance, became unnecessary.

• Location turned out to have multiple representations, depending on the content type, so it became an attribute of several content types.

• Session Format, Topic, and Track were really data about a Session and so became three of its attributes.

• Hotel was a boundary object and did not warrant us creating the content type or data relationship in our content model.

These were the choices we made for our use case. They are not necessarily the “right” choices for everyone. A different set of people modeling a different conference could have made different decisions and still ended up with a perfectly good model. Even another team working on the IA Summit could have put the model together differently. As long as you are making informed, collaborative decisions, you’ll end up with a useful model that reflects your business rules, scope, and resources.

How the Content Model Is Used

There you have it: a visual representation of the types of content you have, their attributes, and connections. The content model does not consist of CMS requirements, but it will certainly be used as a basis for creating them. (Don’t worry; we’ll show you how to do that later.) It isn’t a site map, but it is a guide for creating one—and it’s a heck of a lot better than categorizing your content by format and making that your navigation menu. Although you didn’t design an interface, you’ve thought about the parameters of all the ones you could create. You’ve deliberately staked a claim in your subject area by deciding what matters to your audience and to your business.

With the thinking you’ve done, you are in a position to create richer connections in the websites and products you’ll create and to more creatively curate your content. On top of that, you’ve kept stakeholders involved in the design process in a meaningful way without asking them what features or functionality they want on the website or in a product. You’ve also had discussions that involved designers, developers, and content creators, and now they understand the basis for the interfaces they design, the systems they will build, and the content they will create.

We’d like to say that the human relationships you’ve developed during this process are invaluable, but there is a price tag on just about everything in a business. And you might have made the overall price for your digital presence a bit lower by making mistakes and redoing things when it is cheap and when a change can be made in the time it takes to erase or write a word on a whiteboard. Without the modeling, issues are often not uncovered until code is being tested or reams of content have been written. No one wants to redo anything after the budget is spent and time is up.

Much as an architect or a car designer creates a model before building the real thing, referring to it often, you have built a model before creating a digital product. When it’s time to create a new product, enhance an existing one, or decide to retire one, you and your team should refer to your model to remind yourself of what is possible and advisable. Remix, restyle, and reuse your content, wherever it needs to go, by picking and choosing from the same set of criteria. With a complete content model—not just one for a single product—you can develop multiple representations of the same content across channels and systems.