[ad_1]
I thought I knew everything I needed to know about content modeling. So when I took on a project that involved migrating a Fortune 500 B2B company’s digital marketing stack to a headless CMS environment, I expected it to be routine.
But this project challenged just about everything I knew about content modeling. I’m sharing the lessons I learned to help content leaders communicate with developers – so you can learn from the mistakes I made.
What’s a content model and why do you need one?
A content model represents the content structure by mapping the content types, their elements, and the relationship among the elements and types. They often are used to help developers and content teams understand requirements for new content management systems and other kinds of content technology.
Content models help developers and content teams understand CMS and other #tech requirements, says @HeyMikeWills via @CMIContent. #ContentStrategy Click To Tweet
The Language of Content Strategy offers this useful explanation:
A content model is a representation of structured content that surfaces the key content types and their interrelationships. Content types are an essential part of the shared vocabulary between business, creative, and technology teams when talking about what content has real value to the organization and at what cost.
Structuring content makes it easily reusable in automated ways. It means you can avoid cut-and-paste and other manual ways to recreate things.
A content model helps content leaders and developers communicate business needs and goals in projects like CMS migrations.
(If you need a primer on content models, start here: Structured Content: Get Started with Content Models.)
Content model optimization in theory
To help my Fortune 500 B2B customer, I started with familiar content modeling principles, like using semantic types, reusing content, and mapping to schema.org vocabulary. Not familiar with these concepts? Here’s why your content model should take each into account.
Semantic types
The ultimate output of a content model should be a true omnichannel content ecosystem that can put valuable content on any device, anywhere, anytime (even those devices that haven’t been invented yet). That means the content has to be separate from its presentation. For instance, imagine a design that includes a call to action with a heading, description, and image to support it. Your design team calls it a teaser. Ask yourself: “Does a teaser mean anything to an email, a voice app, or a mobile app?” Not really. But a news article, blog, or promotion does. For your content to seamlessly travel the omnichannel ecosystem, it must be semantic – named for its content type instead of its display on a template or delivery channel. Content models cannot be typecast, broken up, or designed to fit any single platform, channel, or device. They must provide a meaningful representation of content and stand on their own.
Content reuse
Content models should bake strategies for content reuse. A content model built with reuse in mind lets authors avoid recreating, copying, and reformatting existing content. In software development, this is called the DRY (don’t repeat yourself) principle. An article, event, promotion, or even a little snippet like an author bio could be reused many times. Good content modeling should result in a system that lets authors create a piece of content once and reference it wherever needed.
Schema.org mapping
A good content model feeds content to search engines. For content to reach people on the public content channels (like search sites), websites must embed structured content and content models must map to schema.org types that search engines will understand. This strengthens search relevance, drives accuracy, and even increases the likelihood for content to appear as a featured search snippet at the top of SERPs.
A good #content model feeds content to search engines, says @HeyMikeWills via @CMIContent. #ContentStrategy #SEO Click To Tweet
But you don’t need a starship to get down the street
My team and I set out to create a content model with semantic types that enable content reuse and are meaningful in any delivery channel – including search engines.
To make all content reusable, the model treats each piece of content – no matter how small – as a valuable asset.
But, as we soon learned, our impulse to optimize for one aspect – reuse – would nearly sink the content model.
We started to build the CMS with a traditional tree-based organization. Since the content was to be reusable, we organized it in central libraries. One library contained snippets, another held lists, another held promotions, and so on. This approach created all sorts of little, highly organized bits to compose a web page.
This CMS organizes content in a tree of items and folders. An author creates a page as an item for it in the tree. However, to populate the page with reusable content, the author pulls or creates reusable items in separate, central, shared folders of the tree.
This illustration can help you imagine the process. On the left, the tree has a content item representing a page at the top. Several content items below that represent separate reusable pieces of content. In the middle, the form the author must complete for the content item. The author links the reusable content to the first item to compose the web page on the right. In short, to support the ultimate content reuse, each piece of content must be authored separately, organized in a separate place of the tree, and linked in the page to create the whole.
It was beautiful. We created what I thought was a rational content model stuffed with reusability.
And I was right. On paper.
But this beautiful content model created a cumbersome authoring experience. To build a page, you had to find the right part, jump to another library to find the piece that would fill it, link that piece to the page, and repeat that process multiple times.
The beautiful, rational #content model on paper created a cumbersome authoring experience, says @HeyMikeWills via @CMIContent. #ContentStrategy Click To Tweet
We made every conceivable part and piece of content reusable – and created an authoring process that would be too complex to maintain.
Yet, as I looked at the page’s content, I realized most of it would likely never be reused. We had created a vehicle with all the whizbang options and power of a starship just to use it for a daily drive to the grocery store.
Content model optimization in practice
Luckily, we learned many lessons from using the authoring experience with real content. We realized even more as we built a new model, this time focusing on making it easy for content authors.
Though your content model will differ from the one we built, take in these important considerations.
1. Consider more than one content model
Using one master content model forced us to create many small reusable bits of content even though the content wasn’t likely to be reused. This approach hurt usability and flexibility. For our improved real-world attempt, we divided and classified content between two models:
- The master content model defines core content and prioritizes reusability across multiple channels (not just the web).
- The channel-specific model accommodates fast-changing website content types like sliders, heroes, and mega menus that aren’t typically reused.
As developers, we preferred semantic types. But we still created (non-semantic) types for web-specific conventions like a spinner or mega navigation. This dual-model approach let us achieve the best of several worlds: content reuse, omnichannel support for valuable content assets, and flexibility and fast iterations for the website.
A dual content model approach can achieve the best of several worlds: reuse, omnichannel support, flexibility, and fast iterations, says @HeyMikeWills via @CMIContent. #ContentStrategy Click To Tweet
2. Plan for flexible content organization
Separating core content and channel-specific content helped us realize that not all content needed to be reused (and, therefore not all content needed to live in central libraries). This freed us to create easy, flexible solutions for creating and organizing page-specific content.
We allowed single-use content to be organized with the page it belonged to. This brought together most of a page’s content and made it easy for producers to find page-specific content without hunting it down throughout the content tree (see the illustration below). Authors have the option to move pieces of page content into the central libraries for reuse. This approach provides a transition path as the authoring team learns to collaborate and create reusable content.
Organizing page-specific content together reduced the need to search and navigate a content tree.
3. Put authors ahead of code
A content model (and the technology it enables) must serve its primary customers: content authors and web producers. Yet to create it, you’ll need to work with people with technical backgrounds. People with technical backgrounds think in terms of code architecture.
A #content model (and the #technology it enables) must serve its primary customers: content authors and web producers, says @HeyMikeWills via @CMIContent. #ContentStrategy Click To Tweet
Too often, this thinking leads to a content model that serves the code instead of content authors. Developers sacrifice the author’s experience for the sake of theoretical benefits (like flexibility, maintainability, and code reuse) because they haven’t imagined or experienced the impact of these decisions. The only way to know how your content model affects the authoring process is to try it.
In the model we built, for example, the business identified a page type that needed multiple sections of content. The page type would showcase their software products, and they wanted to display the sections in tabs.
Our technical instinct was to focus on the page layout and to keep the code simple. We decided to define two content types: “tab section” and “tab content.” At first, this seemed like a no-brainer. It would provide the customer with the most flexibility to accommodate design changes.
However, this developer-driven approach would have produced authoring problems. As illustrated below, each tab would have to be created individually. Then the author would have to create a content item that represents the tab section and find and link each of the tabs to it. Finally, the author would add that tab section to the software page.
Imagine following that process for many pages on the site.
A code-first or layout-centric approach can lead to a cumbersome authoring experience.
When we dug into the requirements a little more, we discovered the business wanted four meaningful sections – an overview, specifications, pricing, and related resources – on each software page. It was more valuable to recognize the semantic meaning of this content with distinct attributes on the software model than to focus on displaying this content as tabs.
With this realization, we created one software content type with all the fields necessary to render the overview, specifications, pricing, and related resources content (see the illustration below). The website could render this content on tabs. However, any other system could understand it.
Most importantly, the solution was much easier to use. Authors could manage most of the content for a software page on one form instead of having to manage separate, tiny bits of related content in the tree.
A content-centric model optimizes meaning and author experience.
Real-world takeaways
If you’re a content marketer or even a content strategist, you probably won’t build a content model yourself. Just remember to convey this important lesson to your development team: Prioritize author usability.
Don’t let your developers forget that the most beautiful code is pointless if it creates a bad experience for users. Ask your developers to walk through the steps to create content before the model is set in stone.
Don’t let your developers forget that the most beautiful code is pointless if it creates a bad experience for users, says @HeyMikeWills via @CMIContent. #ContentStrategy Click To Tweet
That lesson may seem painfully obvious. But it’s shockingly easy to fall into the overcomplexity trap while aiming for a perfect solution.
Cover image by Joseph Kalinowski/Content Marketing Institute
[ad_2]
Source link
