When envisioning your content for any web project, it's useful to visualize your content types before getting started. What are the main bits of content that are unique? What other types are reusable (for example, blog authors or people in general)? In this post, I'll look at how we identified these types, and leveraged the linked entries features of Contentful for running our marketing site, Datica.com.
The universe of programming contains some helpful concepts that are useful for achieving one of my favorite adjectives: elegance. Elegance, for me, represents a pleasing balance between complexity and power. It’s tempting to go crazy with a feature like referenced entries, but it can also increase complexity and make things harder to manage.
In my career, I’m usually building a site for someone else: a marketing team or other group who is producing content using the publishing tools I’m building. Often, we’re not the ones using the CMS; a complex workflow or deeply nested content model can easily confuse the ones doing the publishing.
I find that when it comes to content modeling, it’s best not to over-plan at the beginning, and instead take a more iterative approach. There are usually some obvious types of things (i.e. entities or content types) that make sense as related types, like blog authors or call-to-action banners. Starting with a basic set of fields and adding on as you go vastly simplifies the work rendering that content in your templating system.
In this example, we examine a blog entry, which has both regular and related fields.
|Publish Date||Date & time|
|Categories, Blog||Short text|
|Social Share Image||Media|
|Main Entry||Long text|
|Call to Action||Reference|
|Related Entries||References, many|
How did we go about deciding which fields to make referenced fields (in bold here), and which to remain as part of the core entry? Reusability, scalability and development costs are the primary considerations when planning linked entries. It’s really tempting to go crazy and add lots of custom fields and related fields. These all come with a cost in development time, tech debt and content training and management.
Questions I ask myself and the team I’m building the system for:
Here’s a few key linked entry types that we ended up with and have proven their usefulness:
If you reference something, you must consider what that piece of content looks like when rendered. A button? A simple link? A card with an image preview and other related metadata? What are your fallback and content truncation rules? Some of these problems are managed through content governance, like limiting the length of text fields, or help and error text (all of which happens on the Contentful side, in this case). Other aspects of bulletproofing your referenced content must happen on the template side. In the process of learning Ruby ERB and now, Slim templating for our Middleman static site, I discovered early on that not checking for the presence of fields would break the entire static site build.
I learned early in my career that content authors cannot see or envision these limitations. They need us to train them and the “system” that we build for them to handle missing fields, too-large images or content gaps elegantly with a minimum of fuss.
We have some fairly complex data models involving our Digital Health Success Framework. Right now, that’s managed using hand-written yaml data files. It was such a new concept (layered timelines, complex interactions, lots of little metadata bits on each entry, etc.) that we didn’t know what would be needed at first. As it was a new experimental concept, we also didn’t know if it would take off or not — no sense overbuilding a web product that’s one-and-done.
After a few months, the design and data model iterations had slowed and the data model stabilized. The pace of updates (we added a new layer or dimension, and the time scale changed) also fell into a pattern that we could predict.
When evaluating how much effort to put into making content managed in a CMS, I ask questions such as:
This last point is one that can be a real rabbit hole, sucking you into an inception-like world of complexity and frustration. I've found it's not wise to rely on relationships more than one or two levels deep.
After thinking through the example above for a few months, observing our editorial patterns and analytics, I decided it wasn't worth the effort and complexity to port the data model into our Contentful CMS. The project got done faster and I was able to move on to other projects.