How well you design the content model for your project plays an important role in your website design not just now but even in future. Consider 2-3 years down the line when you have to redesign your website, having a proper content model makes the task easier. It gives you the flexibility to redesign easily, with reusable existing components, or setting up new pages, displaying content across different channels, as and when required.
But even with the importance it holds for website redesign, there is a common tendency to not pay enough attention to it. While we discussed its importance and challenges in the last blog, the next step is to understand how to approach documenting it. Additionally, we will look at the key solutions to content modelling with Drupal.
A content model is essentially the structure of your content types that you will have for any given project. And one of the most common ways to maintain it is to start documenting in a spreadsheet. So essentially for any given content modelling documentation, you need to cover all entities like:
For example, say you have a website for managing different music artists, and you are maintaining the profiles for several artists. So in order to start documenting your content model in a sheet, you need to define the name of the fields first. What type of fields would you have for a website that manages music artists? Name, profile details, and past compositions could be a likeable choice. So once you decide on the fields, add some description and data around why it is required.
A content model documentation is basically supposed to be a live document that you maintain throughout your model. The fields and data you put up here is what feeds into the requirements and is also what the developers pick up. So it’s highly critical that you maintain it.
Now with any CMS project, how you approach content modelling also depends on the type of content. Essentially they are classified into two different categories - Structured and Unstructured content. Here’s what makes them different with respect to the content model approach:
This includes content like news, articles, webinars, blog, events - things essentially which editors would typically enter the content in the form of a form. The editor goes into the backend and fills out the fields in a form, they are very little bothered with what happens at the frontend.
A structured content type follows a list of fixed templates, there might be some changes they want depending on the content but overall the structure of the content or template of the page remains same. Take for instance any news media publishing website, all of their news articles follow the same template. There might be different versions or special long form articles, certain special templates but the majority of content look the same. That is what we bucket as structured content type.
Drupal has a very mature approach to structured content, and nothing much can go wrong in it. But where we mostly face issues, where we have mostly seen issues in the past CMS in Drupal projects is with respect to unstructured content.
Unlike structured content, this has no fixed templates and are usually uniquely designed website pages like the home page, campaign page, landing page, or any special article pages. These pages are usually put together by editors who, depending on their requirements on the different components they want, stitch together these pages themselves.
There might be some pre-defined templates, some regions, inbuilt components in place for the editors to start from. But how the page will eventually look totally depends on the editor and what they decide to do with it.
As a result, approaching this kind of content or pages is a challenge in itself. And while there are a few solutions you could adopt, let’s first delve into what you should avoid while dealing with unstructured content pieces.
Too Many Content Types
In Drupal, one of the ways is having too many content types. For example, you want to change few things in an existing news article template, say an extra field or the font type, or the background color. You do not require to create a separate content type for this, and you shouldn’t because this is something that can go totally out of control. As more requirements or variations come up, you will keep on creating new content types when those content types are actually sharing 80-90% of the fields.
This will result in a lot of maintenance overhead and introduce a host of issues. Plus fixing something may require a lot of regression testing, and you may also have to roll it out to different content types. So this is something you should definitely avoid.
Too Many Fields on One Content Type
Another tempting approach is to keep on adding fields to a single content type. Say you need a gray background on an article, or a font change in one, all of this can go completely out of hand. If you know what you are doing, and it's only a matter of a couple of fields then it might still be feasible. Otherwise it could cause too many issues in your next website design.
This is because you are completely letting your content model be coupled with design and you are letting the design dictate your content model. The next time your design changes, you will have to rebuild your content model from scratch.
So we talked about the pitfalls, and what are the things you should avoid. Now let’s take a look at the approaches that do work well, ones that you may consider for your next project.
This approach does not require any contributed module, you can do this as part of Drupal core, and you can use Drupal’s templating and theming layer to achieve this.
This is a good approach for simpler use cases where the content structure is not really changing. Or when you want to create a separate page, where the structure is same, and you only want some minor variations, you wouldn't want developers to do this for you all the time.
However if the editors require a lot of flexibility in terms of changing the design or the page layout, then this approach will not scale.
Pros:
Cons:
A module in Drupal which is very popular, can be used to create LPs. Out of the 4 approaches, this is the one that can get you structured content. It is the most API friendly approach, so you can use paragraphs module to even build your LPs on a decoupled Drupal architecture where you are using a Javascript framework instead of Drupal for the frontend application.
Another advantage is the components that you add, you can make them reusable. So there are extensions to the paragraph module that allow you to reuse the paragraph content that you create. You can reuse these components across different content types. You can also easily add any new component, or last minute design changes, it's very flexible in that sense.
The disadvantage is that it ties your content model to your frontend design. So Paragraph approach works really well for stacked content pages (one component after the other in a single column), but if you want to create multiple columns or swap things from left to right etc., you start adding those configurations to your paragraph and that means you start coupling your content model with your designs. When you have to manipulate the layout or the template in the front, that’s where you may not see as much flexibility with Paragraph approach as with others.
This is the most familiar tool for editors, especially for those who have been using CMS. It allows you to build unstructured content pages using the WYSIWYG (What you see is what you get) editor. So you can write all of your content, and embed all your components within the WYSIWYG editor itself.
It is a good way to keep your HTML out of the body, and you can still maintain and build a component outside of the body feed. For example, image, slide show, a photo gallery - you could build them as separate entities, and then simply embed them into your body feed.
This approach is very powerful but also prone to abuse because there’s no fixed layout of how the page will look like. So the editors depending on their comfort and skill level with WYSIWYG, and whether they know basic HTML, it can impact their editorial experience.
Some people may like the power this approach brings, others may find it very complex especially if you start adding many inline components into your article. It is definitely not suitable for the decoupled frontend because WYSIWYGs are meant for coupled implementation. The way you set up your components within a WYSIWYG, translating that information into a decoupled application is a different challenge altogether. So this approach is not suitable for a decoupled setup.
The most flexible approach by far, it allows editors to create regions and manipulate templates on the fly. They can create multi-column regions on their page, and pull in components. It has reusable components so there’s a lot of flexibility, easily accommodate changes, add new components to your component library and keep on expanding it. This also gives the highest level of per page control to the editors.
Some of the shortcomings of this approach are:
Now with these four approaches in picture, the next probable question is which one to choose. The answer is it varies depending on the type of project you are dealing with. Any page that you want to build can be done using all of these four approaches, but you also need to look at the editorial experience, how comfortable editors are using it, how much control does the design team want on the page layout- all this dictates the right approach for your project.
Most large projects use a combination of the four approaches. Homepages and other landing pages may use the Layout Builder. More structured content like case studies and products may use template switching to vary presentation as needed. A shared library of components can bring in efficiency and design consistency across different approaches for managing unstructured content pages.
In EzContent as well, we use a combination of these approaches. It is a one-stop Drupal solution which utilizes AI and machine learning algorithms to deliver an enhanced editorial experience.
What's essential when you are going for a mix of these approaches is to ensure that your components are reusable. And that's something Drupal is great at, if you use the right modules, and create the components in a proper manner.
Thus, working on your content model, and trying to build it in a way that's decoupled with your frontend as much is feasible, are some of the things you should strive for when taking up a CMS project.
Looking to enable editors with an easy publishing experience? Let’s do a little brainstorming and see how we can help.