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 and on the majority of these sites, it's very common when you press the create a new page (or block) button you get presented with a list of 40-50 pages/blocks. 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. However, a year or so later on when all the people who designed the website have moved onto other things, problems occur.
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:
Full Duplication Mode. Create a new template/block for each variation. In my opinion, the main issue with this approach is that you end up creating x number of additional classes/views which make future maintenance a nightmare. For each block, you need to create the block definition, a view model, a view, a controller, a unit test file. If you have 10 very similar blocks and you go full duplication, you'll be creating 100 files that will need to be managed in the future!!!
Content editors will also be presented with 10 options that they need to remember. Speaking from experience, a promo and a feature block might seem obvious now but ask me in a year's time and I'll have likely forgotten the difference.
A Configurable Block: If you have very similar data models, e.g. the same data model used with different UI, it's easier, in the long run, to create one page/block and then put a selection factory to allow content editors to toggle the different views/options.
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 it's intended purpose, that's the point where you can move it into a new block, or, page. Fewer pages and blocks with a configuration first mindset will save you a lot of time and hassle... and weeks of refactoring!