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.
#What is content modeling?
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.
Breaking down a content 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:
- Post: The main content for a single item in the blog
- Author: A document containing information about the author of a blog post
- Category: A document with information about blog categories
- Asset: A document for images, videos, audio, and other multimedia content
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:
- Title – String
- Publish Date — Date
- Body — Rich Text
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.
- Author — Reference to Author model
- Categories — Multi-select reference to Category model
- Assets in Rich Text — References to Assets model
- Featured Image — Reference to Assets model
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.
#When should you think about your content model?
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.
#Why does content modeling matter?
If we recommend content modeling happening first in creating a plan, we probably need to back that up with sound reasoning on why content modeling is that important.
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.
The primary use case and user needs
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:
- Show vs. Movie
- Genre
- Actors
- Directors
- Keywords
- Content Rating
- User rating
While browsing for content, a user will also need certain information to decide if a show is what they want to watch.
- Trailer
- Preview image
- Description
- User ratings
Data structure
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.
Reusability
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.
#Who should model content?
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:
- Content creator — The main user of your CMS. When creating a model, their needs are important to keep content flowing at the right cadence
- Designer — Whether you start with the content model, wireframes, visual designs, or code, the team designing your project should be involved in thinking through the design of your content as well.
- Business leader — This may take the shape of your CEO, the lead stakeholder of your project, head of sales or some other person in your organization. Whoever is looking out for the business need, should have a seat at the table.
- Development team — Whoever is building the project needs to keep an eye on how the API will take shape. While bad content modeling can hamper content entry, it can affect developer efficiency as well. At worst, it can also directly affect performance of your application to your end users if built inefficiently.
- Content strategist/designer — If you’re one of the lucky few to have a strategist or content designer on staff, this person should be the point of this team effort.
#Where should you model your content?
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.
#Conclusion
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.
Blog Author