Let's learn everything about content modeling: the who, what, when, where, and why of a meaningful content system.
Content is everywhere. From marketing copy on your packaging, to the digital menu at your favorite restaurant, to the videos and data in Netflix, to the blog posts and information that power every website, content is what makes the world move. While a broad definition of “content” may seem problematic at first, when we realize that all information presented to users of our products and sites should be meaningful, it opens doorways for enrichment, collaboration, and conversion.
When so much is categorized as content, the structure, strategy and planning becomes a huge concern. Content modeling is the root of how we create systems to expand our content strategy in meaningful, measurable ways.
The content model is the blueprint of how your teams and content work together. It defines the type and structure of your content. The model describes what kind of content you want to store, how it relates to each other, and in what way it can be edited within your system. It is one of the most important components of your project and your model's quality will highly influence the daily life and satisfaction of your developers and content creators. No matter how much work your CMS has put into a solid editor or developer experience, it can be ruined by a subpar content model. Without proper structure, the data becomes a slog to edit, modify, and access.
If your developers struggle with the API and your editors struggle with the CMS, the result will be a poor user experience for your customers. When you spend energy fighting systems that are supposed to help you, you don’t have the time to create amazing experiences for the end user.
A full content model describes all the types of content within one system, how those content pieces relate to each other, and how they can be accessed and remixed. Each individual model type is composed by multiple field or data types such as strings, numbers, dates, assets, references, booleans, and even rich text. These primitives allow for not only a CMS to display proper editing fields, but allow developers to have faith in the output of each model.
A standard blog may seem simple, but with a little forethought, we can make a set of models that will serve our business needs for years. A blog should contain multiple model types:
These model types represent the main content types, but they’re broken up further with various field types. If built properly it creates a sense of building with content LEGO blocks instead of simply writing content.
A post is then broken down even further. Let’s cover the basics, a blog post at its minimum requires some standard data:
For the most basic blog, that might make sense, but when we start to organize and remix this content, it makes sense to extend it further.
This will cover many use cases for our site, but with a little more forethought you can add additional information to cover additional use cases as well. You could create a set of metadata about the blog post that would work for an RSS feed, for SEO, and for social sharing.
The same can be done for the other models, as well. While Author and Category may at first glance seem like they just need a string for a name or title, the more detailed the metadata, the more use cases they serve.
For instance, when adding Author and Category references to a blog post, we can create a bi-directional reference. What this means is that the Author information is available to the Post, but all the Posts associated with the Author or Category are available on those models. This gives the ability for our development teams to easily combine this information in whatever way makes sense for our use case.
Modeling is usually done very early in the lifecycle of a project and mostly taken care of by developers or product managers. Early decisions can have a long lasting effect on the whole project, so make sure to invest enough time into planning.
While a content model can be adjusted at any time in systems like Hygraph, and working with things like Hygraph’s environments can make it safer, the later a change is introduced the harder it will become. Once changes reach a certain level, you may end up needing to do a content migration. Again, this is possible, but ends up costing more resources — either doing data entry or writing migration scripts. By investing more time in setting up a potentially future-proof content model, you will be able to prevent future mundane work such as content migrations.
While modeling should be done as early as possible, ideally, it’s the very first strategic stop on a new project — whether website, app, product, marketing campaign or something different.
In short, a content model is a direct representation and merging of business goals, user goals, editor needs, and developer needs. With a bad content model, at least one of these groups will suffer.
With a focus purely on developer and user needs, the content editors may find the CMS difficult to use, too fragmented, or too verbose.
If the focus is purely on editing experience, the resultant content API may be difficult for developers to work with.
If the business case is the only focus, content editing and developer experience may both suffer.
Let’s walk through some strategic points to think through when coming up with your modeling strategy.
Most of the time, when starting a project, we need to think through the primary use case and user needs. For example, let’s think through creating a streaming application for movies and TV shows. To start the process, we want to examine the use cases and how a user will want to use the application.
A user will want to be able to search and find content based on multiple criteria:
While browsing for content, a user will also need certain information to decide if a show is what they want to watch.
The user case is important, but how will we actually build that use case? We need a solid foundation to build upon. This is where the overall data structure comes into play.
At first, a movie and a show may feel similar in their data structure. They both have all the data mentioned above. And there’s a lot of overlap in how users will want to search and discover. Those data pieces can remain the same, however, the structure of the media is completely different.
A movie is a one-off piece of content. If we structure the content and data around what a movie needs, an editor or developer will need to fill in gaps. Imagine having to enter all the data listed for each episode of a series. You’d have an editor revolt. A TV series has multiple seasons and each season has multiple episodes. The show, each season, and each episode will need some combination of this information, and that information should cascade, filling in blanks as it moves up or down the hierarchy. An episode can have a specific content rating, but if it’s not filled in, an episode can inherit the content rating of the season or series.
By planning ahead and thinking through content rules, we can map out an entire user journey and create the best possible data structure with the least manual data needs.
One of the major benefits of proper content modeling is how you can reuse and integrate your content into any website or application.
If you are planning to build a sustainable content strategy and plan to integrate your content on several platforms such as websites, native mobile apps, smart TV apps, or any future-proofed platform, you should keep your content model clean from presentational information.
While a browser may be able to interpret a specific “Page” model, a native mobile or TV app might not be able to. Keeping your model free of presentational information and only focusing on the actual attributes and relationships of the represented content itself is called semantic modeling and will help you reusing your content for a broader set of applications.
If on the other side, you only want to integrate your content on one specific channel, like a website, there is no harm in structuring your content closer to the component structure of your frontend. This will allow content creators to work more independently on new sites or landing pages without the need for aligning each time with the development team, in case they have a broad set of components to choose from.
Either path forward in reusability presents challenges, so the decision should be made early and with as much input as possible.
Content modeling is not the domain of a single person. With as many business areas and priorities as the model touches, a team should always be consulted. Depending on your project, here’s a list of teams or members that should be involved in the modeling process:
Ideally, you should be as nimble as possible. You can certainly start a process in tools like Google Sheets or Excel, but the sooner you’re inside your final content platform, the better.
This will allow for your editors and developers to begin seeing where there are inefficiencies in your content model. When deciding on platforms, make sure it’s as easy and quick as possible to model out your content exactly as needed. If it can be done collaboratively inside a meeting, this can also go a long way toward providing trust and buy-in across all the content stakeholders on a team.
Enter a platform like Hygraph. Hygraph allows for on-the-fly content modeling across a wide array of field and data types. Hygraph also allows for multi-environment set ups. Meaning, you can start your project simply and as you work together on the model, create separate areas for testing ideas of content structure without affecting the production data. Perfect for when you already have a project running and want to make a large addition to it.
Content modeling is never easy, but it’s an integral part of any project. It may seem daunting at first, with so many variables and factors to consider, but the benefits of investing time and effort in this area are numerous. By taking the time to plan and structure your content, you'll be able to ensure that your project runs smoothly and efficiently.
