On every project I've worked on in the past few years, a recurring theme is that UX/design create a number of similar components with slight variations. An example of this might be a promo block, that has the same data model, e.g. text, summary and a call to action, but has different image sizes etc.. this poses an interesting Episerver design question, how do we deal with this duplication? In today's post, I'll cover the options available to you and explain my recommendation.
How To Deal With Similiar Data Models Within Episerver?
Over the years, I've built and reviewed a lot of Episerver websites. In the majority of these sites, it's very common to be presented with a list of 40-50 pages/blocks when you go to the new item page. Content modelling can be a hard task and getting the right mix of components can be a challenge. When the site was built and weeks of discussion went into the UX, the difference between a spotlight block and a feature block might seem obvious. Fast-forward a year, all the people who designed the website have moved onto other things. With the project creation team gone, the editor experience is hard to understand, resulting in a clunky user experience for CMS users.
When you're building a website if you find yourself in a situation where you have a number of common backend data models with different frontend UI's then you have three main options:
One Component Per UI Design: This approach is the one most content modellers tend to pick. A new template/block for each UI component. In my opinion, the main issue with this approach is that you end up creating more code than you need. You end up creating x number of class definition files, controllers, view models, and views. This makes future maintenance harder. You also x5 the number of things you need to unit and integration test.
If you have 10 very similar blocks, you'll be creating 100 files that will need to be managed in the future!!! Content editors will also be presented with 10 options within the Episerver 'create a new component' screen, making that screen harder to use. Content editors will need to have more domain context to use the CMS easily. Speaking from experience, a promo and a spotlight might seem obvious now, however, ask me in a year's time and I'll have likely forgotten the difference.
The benefit of this approach is the ability to change. If each component has its own files you are free to update each component as you need. I tend to find this argument less of a compelling story. In most companies, if you need a new type of component, you end up creating a new block anyway!
A Configurable Block: If you have components with very similar data models, e.g. the same data model with a slightly different UI, a second approach is to create a single page/block and use a selection factory to allow content editors to toggle the different views. This simplifies the CMS and can dramatically reduce the number of options that content editors are presented within the CMS. Fewer options will result in a better content editing experience!
Giving people fewer options to pick from usually makes everyone happy. If you find a point where your model is straying too far away from its intended purpose, then that is the point where you can move it into its own component. Fewer pages and blocks with a configuration first mindset will save you a lot of time and hassle... and potentially weeks of refactoring later on!. Using this technique it would be easy to retire a block globally in your site and replace all instance with a different view. This would be a simple if or `switch statement inside a controller.
There is no definitive right or wrong answer to content modelling, however, I suggest you favour simplification when designing your Episerver powered website. Happy Coding 🤘
