How not creating new content type elements helps evolving your content model
You’re sipping your morning coffee when an email arrives. “Could you add a new text element so we can fill in the Author name in the Article content type that you modeled a couple of weeks ago?” it reads. Without much delay, you log in. You add a new text element named Author. And you log off and go about with your daily responsibilities. That’s how it usually is. Is it, however, the right thing to do?
Things can get complex really fast
This approach might complicate things. Doing this weekly, you end up with 50 new elements every year. Is this sustainable in the long run? Editors favor short forms with only a few clearly defined elements. Developers want stable and predictable content models.
Is the answer not to create new elements? Not really; the content model should evolve to address evolving needs. What can be improved is the default way of working. Having a standard process is great if you also analyze underlying requirements.
How to guard a content model
Now back to our morning coffee. Let’s replay that scenario. You are the guardian of the content model, so it’s ok to ask for more context!
You read the email. Now let’s get a bit more information:
- What are the advantages of adding this new element?
- How does this benefit our customers and employees?
- Are there any alternative solutions you’d be happy with?
- What roles or users will be entering this information to streamline their experience?
- What can help to ensure data correctness and simplify entry?
- What other content types would benefit from this change?
- What are the guidelines that will help with data entry?
- What’s the naming convention to follow?
Getting these answers will let you make better decisions.
How getting more context helps
The Article content type doesn’t exist in a vacuum. The information about the Author might be accessible in the content model somewhere else. There can be a content item linking and grouping all the Author’s articles. That means the information about who wrote the article is already included in our content model.
After checking the content model, you conclude that this information would help. Still, there might already be an Author content type that can be linked instead, so you simplify content entry from free-text to a simple selection.
Getting information on the responsible user or role will give you insights helping you to set up permissions and the workflow.
Validation details allow you to simplify content entry too. They also help with storing only valid values.
Guidelines are handy for new employees as well as for not frequently used elements. They help to convey to editors what they should do and how the application behaves by changing this element.
Let’s zoom out. The new functionality you plan to add might be helpful for other content types as well. So let’s do some research about reusing it somewhere else, enhancing more content types at once. With Kontent, you can use content type snippets.
Beyond simple text elements
This fictional scenario talks about an Author—a simple short text element. It’s helpful to apply this thought process to long-form elements as well. You can reuse descriptions as chunks in different places. SEO metadata fields, social media posts, or email templates can then reuse the same exact text.
Approaching content model changes with additional context helps evolve your model. It will be more reusable, future-proof, and stable. It will simplify work for editors and developers alike, making all stakeholders happy.