Content-driven development
Empowering non-technical editors to make structural changes to a website without the help of a developer.
Content-driven development is the practice of using editable content to drive the behavior of code. This can be as simple as having a title field that renders text within a <h1> element on the page, but can be taken as far as dynamically driving page structure, layout, and styling.
# Control code through content
The primary benefit to letting content dictate more than just text seen on the page is that it empowers non-technical editors to be able to make structural changes to the website without breaking it and without the intervention of a developer.
# Avoid developer intervention
Building websites is a lot of fun for developers. Making small adjustments to accommodate the ongoing needs of editors after the site has been launched is not as much fun.
When content drives the structure and behavior of a site, anyone who can edit that content can control that structure and behavior. The more power developers can put into the hands of editors when handing the project over, the fewer smaller tasks and feature requests will be needed following the site's launch. That's good for everyone.
# Apply guardrails to behavior
Ultimate flexibility is provided with access to the markup rendered on the screen. This is possible with direct access to the code. For many years (and still today), developers have provided editors with ultimate flexibility by opening up control over the HTML code that the browser renders.
This is very bad in practice. It's hard for developers to get HTML code right, let alone someone who doesn't write code all day.
Content-driven development promotes editing through some interface that stores content in a structured way. This means that developers choose the degree to which a page can be edited, while editors have much less chance of breaking the site. This is because the changes being made can be expected.
# Degrees of composability
There are two ends of the spectrum when it comes to how composable (flexible, customizable, etc.) a page can be. Template-based pages are rigid and map fields directly to a location on the page, while composable pages provide a flexible way to structure and style content.
# Template-based pages
Consider a blog post. Most sites have an expected design and structure for blog posts. The heading, body, and other meta attributes will have a predictable position and style on the public page.
In cases like this, having structured content models that represent these fields makes a lot of sense. It maximizes the productivity for editors because they don't have to think about where content belongs or how it should look. They just add and publish the content.
# Composable pages
Many sites have other pages (e.g. landing pages) where the style, structure, and layout of content is highly dynamic. It can often vary greatly depending on the copy and purpose of that page. In this case, editors should have more control to be able to control the visual output of the page.
Let's look at an example that combines structured content with composable pages.
Here, the page object coming from the content source is a structured object that has an id attribute (home-page), along with an embedded array of component data, as the sections property.
This sections data get mapped through your code (shown in the next graphic) to create a page made up of flexible content. This enables content editors to compose pages in any way they want.
This particular process varies from project to project. The simple example above is a stripped-down version of a JSX page that would handle the rendering of content in the browser shown on the right.
# Find the right balance
The key isn't giving editors flexibility, but finding the right degree of flexibility needed to meet their needs.
Many site builders struggle in this area because they go too far with flexibility. And every bit of flexibility you add makes managing the code more complex.
Therefore, flexibility should be introduced to the degree to which it best serves the site and its editors. A blog site probably doesn't need much flexibility, while a marketing site that consistently runs new campaigns is probably going to need to be much more flexible to serve the changing needs of each campaign.
# Use Netlify Create for balance
This is where Netlify Create comes into play. Our visual editor is designed to flex to the needs of each individual editor by providing control for developers to introduce the exact degree of flexibility needed for each site.
Did you find this doc useful?
Your feedback helps us improve our docs.