Content modeling: creating structure and navigation

Websites are still a vital part of the expanding range of digital experiences offered across many devices and platforms. There’s no doubt their creation and maintenance take up a sizable chunk of a digital team’s time, effort and brainpower. Unless you want a lot of unhappy editors, you can’t build your content model exclusively around the needs of developers.

Making the right decisions early on will keep both groups happy. We’re big fans of Contentful’s flexible infrastructure, but we understand that the initial planning and building phase can overwhelming.

That’s why we created this white paper, which explores three structures that can serve as a foundation for a navigation content model. Each is suited to different types of sites, so it’s as simple as choosing one and then making it your own. You can also come up with a hybrid model – it’s all about creating what best suits the project.

Before you even touch the content model, however, it helps to create or revisit your content strategy. The goal of a content strategy is to create a meaningful and consistent experience for the customer. It often encompasses auditing, planning, structuring and testing content.

Once you have your content strategy down, you can start creating a content model. A content model consists of individual content types, and gives structure and organization to the content by documenting all of the different content types involved in the project. It helps to think about content types as lego pieces that can eventually come together to build something amazing.

Creating a website navigation model that works well for both editors and developers is a key challenge, and can cause even the most proficient content modeling experts to become unstuck. But when it’s done right, it becomes a power tool that improves workflows and productivity.

Check out the full white paper here, or keep reading for an abridged version.

Here are three structures that can serve as a starting point to a navigation content model.

This model is great if your content is purely topical content that is then parsed or rendered using a different set of things. Ultimately if the raw ‘things’ in your content are related to one another – and that is how you want this information to be represented – then this pattern may work for you. One example would be a hotel chain. Each hotel has a relationship with all of its rooms, which each have different services and amenities available. It doesn’t matter where this content is being displayed (in-room or online), the relationships stay the same.

The assembly model allows content creators to put individual content types together to build web pages, documents, apps or other content products. If the content is designed to be specifically displayed on a website, and the page assembly is the core way users access the content (via a URI for example), then assembly relationships may work best for you. If your assemblies have children that are topics, they can also have children that define those relationships –– but it is important to note that the pages have relationships, not the topics themselves.

One way of thinking about navigation is to flip the above approaches on their head and create a content type specifically to hold navigation information. You’re then able to structure pages or topics as references within this content type. This allows for multiple navigation elements that can be especially useful if the website or application has different menus.