A Useful Guide to Content Types, Part 2

When we first started building websites, they were “static,” meaning each page was coded individually and published by putting files on a server. Today, we have content management systems (CMS) that allow us to turn every piece of content into data, with technical content types. To be sure, web pages still exist, but we must think of them as the display of a specific set of information, not the structure of the information itself. Because we cannot predict how our content might be used in the future, we need to set up content types to be prepared for anything.

Are you ready to use content types to bring your team together to create, publish, and manage content more strategically?

The first part of this guide to content types showed why they are good for making sure content is flexible and future-friendly. Content types are essential to effective and efficient content management.

Knowing why content types and their structure are beneficial is only half the battle. Creating content types for a content management system (CMS) can be tricky. There are many aspects to consider when defining which types to set up and how to separate and specify the fields. Nuances abound, as you’ll see in part of the guide. They should not be left to a developer to figure out at the eleventh hour of a site build. Let’s see how to define them and how they can be part of your workflow as soon as you decide to start using them.

How do we find content types?

Creating content types is as much an art as a science. There is no right way or wrong way. The process is less important than the outcome: a set of content types that allow you to manage and use your content effectively. Here are two paths to determining which content types you need:

• Existing content—Looking for patterns in the content you already have to discover content types
• Domain model—Starting with a real-world representation of your subject area and narrowing down to the content types you want to expose

Patterns in existing content

Most of the time, by the time we create content types, there is already an existing site or app, or at least an inventory of content. During a content audit, patterns can be found that lead us to identify different types of content. Use these patterns to separate the content into distinct content types, each with its own set of properties.

Each content type should define a single thing. Remember that a content type can also have relationships with other types. Capture every detail about that thing when defining the attributes of the content type, regardless of where you might want to ultimately display the content. For example, the Spacecraft content type would only name the craft type, not describe it. What this means is that instead of talking about Space Shuttles (the craft type) generally when describing the Space Shuttle Enterprise (the spacecraft), stick to the attributes of specific instance of the thing that gets built and sent into space.

Start with a domain model

A domain model is an alternative to starting with existing content, as Mike Atherton and I explain in Designing Future-Friendly Content. A subject domain model is a representation of concepts and relationships that exist in the real-world, not an interface. Permanence is created by starting with concepts that exist in our audience’s mental models, outside of our organizations. It does not care what is in our existing content inventory. In that way, it takes a much broader view of the content that could be created.

Here is a domain model for the subject conferences.

This is generic enough that it could be used for any conference yet it matches how people tend to think about a conference. Do not yet define attributes for any of the concepts, though examples might be noted to make sure they are at the highest level. For example, Venue, Hotel, and Location all have a number of examples, which make them viable as concepts.

Concept: Venue
Examples = Hyatt Regency Minneapolis, Omni Atlanta Hotel at CNN Center, Sheraton Inner Harbor, Target Plaza Commons

Concept: Hotel
Examples = Hyatt Regency Minneapolis, Omni Atlanta Hotel at CNN Center, Sheraton Inner Harbor

Concept: Location
Examples = Minneapolis, MN; Atlanta, GA; Baltimore, MD; Nicollet Lobby, Northstar A, 300 S Charles St, Baltimore, MD 21201

From the domain model, we can choose which concepts to expose in our interfaces and create content types for those.

Creating a content model

Together, these content types create a content model, which is a representation of types of content and their relationships. This can be created with stickies and a white board, writing out the properties and drawing the lines between them to show relationships. At this point, it is still easy to make changes to which content types you have and how they relate to each other. Because it’s visual, it is easier for stakeholders or clients to understand and maybe even get involved in creating them.

When starting from a domain model, concepts become content types, which have properties. At this stage they are still abstract and contain real world properties. Since we are thinking about their eventual representation in an interface like a website, we might assign properties that are specific to the web, like URL or Twitter ID.

When starting from existing content, you can go right to this step. Because it’s still fairly theoretical, the stickies used in this model could be created during the audit process as potential content types are identified.

It is important that we apply the “Goldilocks” test to the content types in our model: not too many, not too few. Too many and they risk becoming only viable for a single instance. Too few and they don’t do their job of separating content into meaningful structure. So we must always ask if there is enough uniqueness for a particular set of content to be a content type. Maybe there are several types of content that all have the same set of properties but need to be categorized by format. In this case, you could have a single content type for all of that content but include a property that identifies which format it is. Sometimes one concept is actually a property of another.

Using the examples of Venue, Hotel, and Location from the conference example above, we find that the hotel and venue are essentially synonymous, and so Hotel does not need to be a content type. Location can mean many things and so it becomes a property of several content types, as seen in Figure 3. The choices made at each step of the process get us closer to the best set of content types and their respective properties.

On the other hand, if we find that too many properties of a content type are specific to one type of instance, it needs to be divided up into two (or more) content types. Take an Event content type. There could be many types of Events: Conference, Webinar, Networking Reception. It might seem like they are similar enough, having names, dates, descriptions, unique URLs, and fees. But when we dig in, we find that a Conference has a central location but also sessions (with their own locations), fees, a chairperson, a logo, and multiple days. Whereas a Webinar has none of those things, being not only a single day but having a specific start and end time. And Network Receptions don’t have speakers but do have sponsors and might be part of a Conference, or it might be its own event. Since the structure of each is fairly unique, we divide them up but give the shared properties consistent names: Event Name, Date, Location.

Defining technical properties

With the content model complete, it is time to put the content types and related information into a spreadsheet. This spreadsheet (here’s one you can use) provides the implementation team with all the information they need to bring the content types to life in the content management system (CMS). It will include Content Type Name, Description (of how the content type will be used), and the properties and their datatypes.

From the IA Summit conference content model, the technical specifics look like this:

Input Field	Field Title	Field Type
Content Type	Person	Content Type Name
Description	Info about people associated with IAS	Text (plain)
Title Field (change label to)	Full Name	Title
Body Field (change label to)	Bio	Body
First Name	First Name	Text (plain)
Middle Name	Middle Name	Text (plain)
Last Name	Last Name	Text (plain)
Suffix	Suffix	Text (plain)
Twitter ID	Twitter ID	Text (plain)
MainEvent	Event	Entity reference
Role	Role	Term reference

These properties have changed slightly from the content model originally developed. For example, dividing out the name into four fields means that sorting lists of people can be done alphabetically by last name, whereas having just Full Name would mean sorting could only happen by first name. This division also makes the content type future-friendly in case only first or last names are displayed somewhere.

The content type is also future-friendly because of the entity reference to the MainEvent. By referencing a different content type (Event), a relationship is created between the two content types. It might be tempting to think only of this year’s event. In reality, the same people are involved in this event from year to year in different roles. This year’s co-chair could be last year’s workshop speaker and next year’s keynote speaker. With this Person content type, the information about the person stays the same no matter what the year and the role. Each year the person is involved in the event a new relationship with the instance of the event can be created without re-entering personal information.

Think about authors too

For stakeholders and marketers, content types are a guide for what content to create. Therefore, these people need to be considered when planning content types. As authors and people who enter content, what parameters to they need?

Keep the authors in mind to determine how rigid or flexible a content type needs to be. If governance needs to be strictly enforced, the properties need to be more rigid. This might include:

• Limiting the number of characters allowed in a property entry
• Providing select lists rather than open text for applying taxonomies
• Limiting the type and size of files that can be uploaded
• Making certain properties required
• Dividing a set of properties into their smallest atoms to reduce complications resulting from someone creating or entering content in a way that affects design
• Using plain text datatypes to prevent authors from using (or having to use) HTML tags

Authors will sometimes complain about this rigidity, but it provides many benefits that are not obvious at first glance. It can be helpful to show them how the structure of content types helps maintain consistency, makes it easier for them to enter content, and allows their content to be reused in various ways.

On the other hand, a content type might need more flexible properties if there truly are multiple choices for what values it could contain. The primary reason for doing this is for large blocks of editorial copy, like the body field of an article or a description field of a Spacecraft.

Designers typically are not involved in creating content types. But once we start defining the structure, consulting a designer and front-end developer will help make the content types more impervious to that first contact with real content in the design. Developers should help define the technical specifications of content types for the CMS. They know best which modules or plugins are needed to set up certain properties.

What will you do?

Now that you know the power of content types, what will you do differently? Don’t wait for a full redesign. It is likely that you can get started setting up content types now and preparing for the future:

• Model your content, without any implementation in the back-end. I did this for one client and they were able to update existing content by creating consistent formatting and using the structure inherent in HTML tags (even if only within the Body field).
• Work on one content type at a time. Model the content and its relationships and modify your CMS and design to work with the new structure. Then move on to the next content type.
• Use content types for new content. If you are creating something new, make sure it is defined as a content type. It takes longer and is more expensive to retrofit something than to create it with the proper structure in the first place.

However you start using content types, know that you are taking a step toward making your entire brand, website, or app ready for whatever your CEO, CMO, CIO, customer, or competitor sends your way.