Content Modeling

A video walkthrough is available for this lesson. Log in with your Sanity.io account to view.

To make your content future-friendly and usable in any channel, it's best to start with a content model.

"Content model" means different things to different people. Here's how we define it at Sanity.

Content model
Documentation of the types of content and their relationships for a given organization or project

The content model should be based on entities.

Entity
A thing or concept that is unique, distinguishable, and self-contained

This should not be confused with instances of those entities.

Instance
Unique and specific content

An Event is an entity while the Taylor Swift Eras concert in Philadelphia on May 13, 2023, is an instance of an Event.

Let’s create a content model for our live music venue management company.

Include everything, not just what’s currently on the website. This is a brainstorming exercise, so no right or wrong answers!

Here's where we started.

Open to enlarge image

The next step is to figure out which of these are content types that we need for our digital experiences.

Content type
a reusable container for storing content that has a common structure

Note that the best practice is using the singular word version to name content types.

We can remove a few things from our list that are important to the business but don’t need to be modeled for our digital experiences.

• Audience
• Staff
• Crew

Others are more a way to classify multiple content types:

• Genre can be applied to Artist or Event
• Tour can be a property of the Event when applicable since we won’t be hosting the entire tour

We then refine the names of the rest of these nouns and make them singular.

Open to enlarge image

Now that we have decided which of our nouns are content types, we define them. This will further validate that these are the right-sized entities. And this will provide clarity for our future selves and our colleagues.

• Artist — Act that performs
• Bar Item — Unit of food or beverage sold at the venue bar
• Event — Show or activity that takes place at a venue
• Job Description — Details about roles for hire
• Merchandise — Goods sold at a venue
• Ticket — Pass that provides admission to the holder
• Venue — A building designated for entertainment events

Maybe you’ve already started to think about how these content types relate to one another. Let’s do that officially now.

Open to enlarge image

There we have it! Our live music venue management company’s content model.

Because this model wasn’t built around any specific interface or content management system, it is a content strategy tool — a way to look at all your content and see what it reveals.

In this case, Venue and Event are our central content types. This makes sense since we produce live music events at our venues! This can inform our websites, our promotional posters, social media posts, and more.

Your organization’s content model might reveal something not so obvious but equally as valuable.

You do not have to implement the whole content model now. It helps you be future-friendly rather than trying to be future-proof. You don’t have to know what you’ll need in 1 or 2 or 5 years. This is meant to evolve as you grow.

Since our short-term goal is to set up Sanity to support our expanded business and the new websites, we will focus on just part of the content model to make sure we can promote and sell tickets for upcoming events. That leaves us with just three content types:

• Event
• Artist
• Venue

Now we can move into planning our schema for Sanity. The schema defines the Studio, which is the Sanity editorial interface where people will create and manage content.

Before we jump into code, we have a collaborative session that includes our marketing manager, web designer, and lead developer. This way we can be sure to create an editorial environment that is sustainable for efficient content operations and provides the material that designers and developers need to create the end-user experiences.

Here’s how we defined the Sanity Document Type for Event:

Open to enlarge image

Some insights into how we decided on the fields for the Document Type.

• The Event Title (field type: String) will be used to identify the event in the CMS.
• For the Event Date & Time (field type: Datetime), we want to be able to pick a date and enter the time.
• Since we don’t want to repeat the date for designating the time the Doors Open (field type: List (30, 45, 60, 90, 120)), we’ll just set a number of minutes before the show time and calculate the time for display on the front-end.
• We’ll have a separate document type for Venue, just we just need to pick it here through a Reference field type.
• We’ll select from a reference list of Artists for our Headline and Supporting Acts. Every event will have a headliner, but not all will have a supporting act, so Headline Act is required but Supporting Act is not — and we want to be able to select multiple Supporting Acts.
• Remember how we removed Tour (field type: String) as a content type? Here it is! If the tour name is relevant to a show, we can enter it here.
• Since most events are self-explanatory, we aren’t making Details (field type: Rich text) required.
• Since we don’t sell tickets directly, we’ll just add the Ticket URL (field type: URL) here.

Now our developer can code the schemas, launch the Studio, and have our marketing manager start to enter content to make sure it all works the way they expect. And our designer will have live and real data to use to populate and test user interface designs.

You might notice that the content model has no opinion on actual web pages. That’s because the content model only has opinions about what the entities behind the web pages are.

The content model will provide about 80% — 90% of the content in any given interface, whether that's a website, an app, or a digital kiosk. You will need additional wayfinding, aggregation, and curated pages to make the end experience usable.

Don’t try to make your content model fit every item of content you’ll ever publish. You’ll get to the remaining 10% — 20% of content when you design the interface.

The purpose of the content model is to define the structure of your information. It is a foundation on which you can build (and rebuild) many applications using the same pieces of content.