A Useful Guide to Content Types, Part 1
Content types are the essential building blocks for a brand, a content management system, and a digital ecosystem. Too often, deciding what content types will be created and what properties they have are decided by a marketer or developer with little context about the content they will contain or how it will be used. Content strategists need to be involved in defining content types so that they support the content that goes into them – and how it comes out.
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. Yet, so often we do not take full advantage of this capability. Indeed, some CMSes are still page-centric and allow limited content types that are not very flexible.
To meet the demands of content in 2016 and beyond, it is imperative that we not only build systems using well-defined content types, but that we think in terms of content types and not web pages. 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.
After reading this article, you should have an appreciation for the importance of content types. In Part 2, you will gain insights into how to better define them. In fact, you may never be able to look at a “blob” of content without shedding a tear and immediately wanting to define its attributes.
What is a content type?
There are many definitions of a content type. Here is a definition I use, which we’ll use for this guide:
A content type is a reusable container for managing content by common structure and purpose.
Content types support the underlying structure that is needed to make content reusable. All content types have attributes, or properties. Each property has a name and datatype. The datatype indicates what kind of information can be stored in that property—here is a helpful guide to datatypes commonly used in content management systems. We give each property a name so we know which property we are referring to at any time.
For example, a Spacecraft content type might have the following properties:
| Name | Type |
|---|---|
| Spacecraft name | Text (plain) |
| Photo | Image |
| Description | Text (plain, long) |
| Length | Number (Decimal) meters |
| Speed | Number (Decimal) km/sec |
| Weight | Number (Decimal) kg |
| Service year | Number (Whole) |
| Craft type | Entity reference (Craft Type) |
Once we have the content type container, we can create instances of that content type. For each property, we enter values. These values become the data for use in interface, search, APIs, and anywhere else our content needs to go or be found. Here is an example for our spacecraft:
- Spacecraft name—Enterprise
- Description—The Space Shuttle Enterprise (Orbiter Vehicle Designation: OV-101) was the first orbiter of the Space Shuttle system. It was built for NASA as part of the Space Shuttle program to perform atmospheric test flights after being launched from a modified Boeing 747. It was constructed without engines or a functional heat shield, and was therefore not capable of spaceflight. It is now on public display in New York City.
- Craft type—Space shuttle
- Length—56.08 meters
- Speed—7.74 km/sec
- Weight—68,000 kg
- Service year—1977
Because content types can be connected by creating semantic relationships, they can be put together in seemingly endless combinations. Content types can create a system that provides meaning based on editorial or curation decisions, or allow users to create their own journey.
Once we understand content types and how they’re linked to the foundational database that fuels them, we’re then able to establish relationships and dependencies between content across all channels.
The classification of a spacecraft as a craft type allows us to create dynamic content displays, such as a categorized list of all spacecraft. It also makes it possible to provide related content on a spacecraft display page – for example, displaying the “Craft Type” as a link that we can follow to see all the spacecraft of that type, which then allows us to select a different spacecraft of the same type.
In the image above, the lists on each page are created and populated dynamically, including categories and specific types. When a new Craft Type “Interplanetary Transport System” and a new Spacecraft “Space X Mars Transporter” are created, the lists in which they appear are updated. Additionally, the detail pages are also automatically created. The Interplanetary Transport Systems will appear above Landers (since the list is sorted alphabetically by Craft Type) and the Space X Mars Transporter will appear below that. Each of the new entries will be a link to their respective detail pages, where they will also link to each other and back to the full list of Spacecraft.
In essence, content types are the building blocks of dynamic, future-friendly content across systems. They provide the structure used by people and computers to explicitly express meaning.
Why do we need content types?
Content types solve several problems for content strategists, authors, designers, developers, and users alike:
- Separating content and presentation makes the same content reusable within a website or across multiple interfaces
- The same type of content gets presented and formatted consistently
- Creating building blocks for use in content creation and interface design allows everyone to work from the same script
- Defining templates for a content management system makes content creation and entry more efficient
- Content can be searched and organized in many different ways
- A content inventory can be expanded to any scale
Let’s take a look at how each of these work.
Content reusability
By separating content into different types that have the same structure and purpose, we can take the presentation layer out of the content itself. Separating the content from the design makes content reusable. We can put all the properties into a content type and decide later how they will surface. There is no telling who will determine how content will be used at a later date.
In addition, when we use a shared data schema for our datatypes, our information is more readily available to third-parties to use. Having our content appear outside of our properties extends the reach of our brand and gives us control over the content. After all, if our content is the source of information for someone else and their systems ingest our content, then when we change something, it gets changed elsewhere too. Just like on our own sites.
Consistency
At the same time as we are separating content from design, we are also allowing for consistent presentation and formatting of like content. With the use of content types comes the use of templates for displaying content. We eliminate guess work on the part of authors – and keep them from breaking the design. Consistency creates a feeling of trust and helps establish your site as a credible source of information.
Governance can be embedded in the content type so that people entering content do not need to decide on formatting or styles. There might be complaints about lack of flexibility, but in most cases, it’s worth the trade off. We wouldn’t want each instance of a spacecraft on our website to look completely different from each other. Inconsistency in design or information offered diminishes the customer experience, thus decreases credibility and loyalty.
Get your team in sync
Content types are building blocks for use in content creation, interface design, and system implementations. When you define your content types collaboratively everyone has proper context for their work and there is clear structure for everyone to work with. This gets your whole team working in sync and in parallel without concern for having someone go down a different path and design, content, and development not match up.
Authors can stay on track with templates that specify how content needs to be created, property by property. Designers can map content types to design patterns and templates for various displays of content. They also have context to make sure the design supports the goals for any given page or template. Meanwhile, developers have context for what they are building. When they bump up against a choice in how to build a relationship or functionality, they can either make a more informed choice or know that they need to ask the strategist or designer for the additional input needed.
By having a series of content types to guide design and implementation, we can all be assured the front-end work will match up with the back-end.
Better systems
“No model survives first contact with real content,” says Cleve Gibbons (building off of Lullabot’s Jeff Eaton), Chief Marketing Technology Officer at Cognifide. He’s absolutely right. By defining the content types, we also identify how much sample content we need to be able to test the system. Because content can be developed in parallel with a CMS build, real content can be created (or reworked) at the same time. The real, proto content can be entered to make sure everything works as desired. If it doesn’t, adjustments can be made before enormous amounts of content are entered.
A model also rarely survives first contact with a CMS. Inevitably something comes up, and changes need to be made to accommodate some aspect of the content or the system. But this is still miles ahead of a typical build where wireframes and handed off to a CMS developer. Plus, having structured content means that entering content becomes more of a data entry task than something that requires subject matter experts (SMEs) to be involved to make sure the content is accurate and is tagged properly. That work is done outside the CMS, where SMEs are more comfortable working.
Search and classification
There is too much information in the world for content to not be searchable. Whether on a website, a global search engine, or a content aggregator, content types help search engines identify content and index it in meaningful ways. Not only can metadata be part of content types, but the content types can become metadata themselves.
In search, content types facilitate advanced search by content type or other metadata incorporated into the structure of the content type. That metadata allows filters to be applied or sorting order to be changed on the spot. Outside of search, listings of a particular content type can be dynamically sorted by the various properties because they are all separate. Maybe there is a page listing all spacecraft with name, length, speed, weight, and service year listed. The default order might be alphabetical by spacecraft name. But a table could be created to easily sort by length or speed or weight instead, depending on how the visitor wanted to use the information.
Scalability
Today, there might be 10 types of spacecraft and 500 instances of them in our hypothetical website. In 20 years there might be 20 types of spacecraft and 10,000 instances of them. And that information might need to be available to 1,000 systems around the world (or on Mars!). Content types allow you to easily expand your inventory of content without having to change what already exists.
What’s Next
So there you have it, six reasons to use content types to make your content work harder. They are not the domain of one function, but help the entire web team as well as content creators. Use these explanations to help others see how structuring content will lead to more success for them and the business.
That’s not all! Stay tuned for Part 2: How to create content types.
