A Content-First Strategy for Building Websites and Apps with Headless CMS

Agility CMS provides you with the capability of creating Content Warehouses and Property Instances

Let's take a closer look at what it means to have a faster mindset and to execute on the content-first methodology – how do you design a system that ensures you'll be able to maintain it from day 1 and for years to come with increasing ROI.

• You start with Strategy.  That means you need to define the Architecture of your content and decide on the Team structures so that you can be productive right from the start.
• You need to have the right technology - and it needs to support  the Content First approach – meaning it needs to support the separation of content from presentation, and so on. We also recommend that you have aspects of your tech stack that are optimized for each channel, and I'll talk more about that in a moment.
• We need to start thinking about Continuous Delivery.  Our Content Workflow builds upon our strategy so that we can continuously push new content to multiple channels.  Developers will utilize those Content First APIs, and they'll use DevOps to keep everything running smoothly as you roll out new phases of your strategy.

Let's talk about that Content Strategy.  After all, your new mindset needs to be strategic in its approach.

• You need a Plan.  You need to think about the goals in the short term and the long term, and how you can achieve those goals with a phased approach.  Who are the people involved, what will the teams look like, and how will they operate together – what's their workflow.
• Then you need to come up with your Content Architecture  - This is how you'll be able to maintain a highly consistent system. You take the time to define the content types and what fields and relationships they have.  This is a critical step.
• Next, you actually start to do some work.  You build out your content instances, you deploy phase 1.  And you start to iterate through the next phases you defined as part of your strategy.

Now let's look at the technology that's going to help us succeed.

• Top Priority in your content technology stack is your CMS.  It should support a Content-First approach. Easy content organization, with page management built-in.
• In terms of the actual tooling, these days, your tech stack needs to be optimized for JAMStack and static site generators. That's the current state of the art for website development.
• And it should be delivered by great partners.  You need trusted developers to continuously deliver iterative updates that build upon your investment over time.

Your tech stack needs should be able to deliver increased ROI over time

The final, and possibly the most important aspect of the Faster Mindset is the idea of Continuous improvement.  Your web presence is a living entity that needs to be nurtured as it evolves and grows.

• It's a cycle that starts with Build.  Build content, build out your campaigns, and developers may be involved with any necessary code updates.
• Then you'll deploy it – you'll be publishing the content, and developers will release the code to your websites and apps.  This is called DevOps.  It's easier than ever to coordinate publishing content with the release of new code.
• And then you iterate. you start on the next phase.  You plan future phases, you optimize, and we start to [click]build and deploy all over again.  These phases are best done in small, bite-sized chunks.  Keep it simple.

Let's review the top recommendations you've seen so far.

• Build your Content Network – you can set up your CMS Instances to store content that is then shared and pulled into any of your digital properties – could be your curated or customized data, anything.  If this data is externally sourced, it's easy to set up a relationship between the external data and curated data using a unique identifier.  That way you don't have to duplicate anything.
• We are recommending JAMStack for website development and specifically React.  A vast majority of the world's developers know Javascript, and React is the most popular and supported framework.
• We recommend deploying to static websites.  This allows your sites to be lightning-fast and much more reliable. It's also easy to test a build of the site before it goes live.

So what does a Content Network look like?

When you look  at designing and building out a Content Network, there are 2 unique ways that we can store that content.

Imagine a single source of truth for the content that's most important to you.  That's something that should be in a Content Warehouse. Then we add in Property Instances that are tied 1-1 with a digital property, line of business or segment of content that displays on multiple sources.  These instances will have the Pages, Modules, Templates, and all the content that is ONLY meant for that set of outputs.

This approach lets you design a system for your Content that will work no matter where it will be outputted.

There are some really clear benefits here:

• A Content Warehouse is an incredibly well-organized, highly-optimized way to store and manage content as a single source of truth in your organization.
• It allows you to keep content that is specific to a particular destination or output OUT of your main warehouse.
• You use Property Instances to give you granular, page-level control on systems that are directly connected to their outputs.

Let's look closer at what a Content Warehouse looks like.

A Content Warehouse allows you to store a set of items, lists, or media that you need to share across multiple properties.

• It's a place to store curated data that will need to be shared.  Update it once, see it used everywhere.
• It could be a chance to important centralized assets, such as logos or shared image and PDF files.
• You can pull in external content into this warehouse, and run it through an approval process before it gets published and used online.
• You can store many types of content, such as centralized Categories, Location Types, Articles, anything that's important to your organization.

A Content Warehouse also allows you to segregate that content into its own functional unit,

• It maintains all its own relationships.
• It has its own workflow.
• It has its own security.

We talked ealier about a high level of consistency.  This is made possible by your Content Architecture, which starts with:

• Content Definitions – these allow you to create content types such as Articles, Categories, Products, Bios – whatever you need to define your content for this instance.
• Each definition can have fields – Basic Fields, text, numbers, dates, urls, etc
• Attachment fields – which pull from the instance's central media repository
• Custom fields – which can pull content from an external source, such as a separate asset manager, or your own custom APIs
• And you can also set up Linked Content – this defines the content relationships in the system.  It's really powerful.

With related content fields, you essentially create the schema that all the content in each instance has to follow.

• Here we have a Category, with one or more Subcategories, which we can link to an Article.
• We can even link that Article to other articles if we wanted to show something like Related Articles.

Now let's take a closer look at how a Property Instance will work for you.

It will contain all the content that is directly related to a particular output, or even a set of outputs. That includes Shared Content, Pages, Modules, and even the Sitemap. 

Now, remember, we want to separate our Content from the Presentation layer, so this is just the Content that will be used on this website or app.  The code itself will take that code and render the content to the screen.

Let's dig into page management – this is a game-changer for both Editors and Developers.

For an editor, it's a simple as creating a page by choosing a Page Template. Then you can add Modules into the available zones and fill in all the content.  Each module is simply a content item with a special name so that developers can identify it and render it using a specific component of code.

Editors can add, remove, and re-order those modules however they see fit. 

For developers, it means they can re-use much more of their code to create granular pieces of functionality.

Developers will setup Page Templates with Content Zones. Then you set up Module Definitions with properties needed to render that module – these are the same kinds of fields we set up in our Content Definitions.  Text, Date, Custom, Attachment, Linked Content.

These modules can be used in different areas, but they might look different based on their field properties.  This enables you to have control over predefined chunks of functionality in the website, while still maintaining that separation of content and presentation layer.

If you are coding in React this is how Page Templates and Module Definitions work. Page Templates translate to Page Components, and we determine exactly how each Content Zone will be rendered. Module Definitions translate to regular Components, and all the fields we defined in the definition are available as props to that component.

So how is Agility CMS different from all the other headless offerings out there

You get more consistent content with Agility CMS because the data has been architected and content relationships have been set up that are easy to work with.

Agility CMS includes Page Management, something that is normally handled by developers.  This allows marketers to set up and assemble pages using pre-built Page Templates and Module Definitions.  Each Module in Agility translates to a React component that gets its data based on how the module is setup.

Add this all up and you are able to move faster and launch new digital properties much faster, and more reliably.