Episerver projects are unique in nature compared to most other web projects. In today's guide, you will learn about some good practice techniques that I recommend you follow when you start splitting your design into pages and blocks. As Spiderman once famously said, "with great power comes great responsibility" 🕷️. Even though on first appearances Spiderman and Episerver don't have much in common, that statement is something you should keep in your head when it comes to architecting your Episerver blocks!
A Case Study Of What You Shouldn't Do When Designing An Episerver Website
I've been working with a company very recently, whose original brief was to create everything as blocks. In theory, this may sound like a good idea, however, there are some pretty big downsides you may not consider at first. The theory is you create one generic template and a block library and give all the power to CMS editors. Having a huge block library will give the marketing department the flexibility to do whatever they want without any intervention from the IT department.
In this example, the marketing department historically had issues getting the IT department to do work for them. When this team were being pitched about Episerver and blocks, they were sold on the idea. They wanted everything created as blocks so they had the power to control their own destiny. I think that a lot of companies and developers make this fatal assumption when first starting to use Episerver as well. If you are a new Episerver developer, if you talk to a lot of us old-timers, I think most of us fell into this trap within our first few Episerver builds. On paper, having everything as a block sounds like a great idea, however, in practice, every client when presented with a CMS designed this way ended up being unhappy with the end result.
In my scenario, the company thought they didn't need to do proper UX thinking anymore. The reason for this thinking was due to blocks. As everything would be a block, they decided to get their design agency to simply create a list of 300 components instead. The content editors knew enough to build a useable website...
Why Too Many Blocks Will Cause You Headaches!
Large projects will have a number of key stakeholders, UX people, designers, developers, product owners, content editors, CEOs, etc... In this section, I'm going to explain why having too many blocks will piss off all of these groups. I was in the pub discussing this situation with a UX friend, who I should probably mention isn't familiar with Episerver at all. When I mentioned the approach the client wanted to take, he immediately understood why having too many blocks will result in a bad user journey. If you design your website based on components alone, focusing on the detail rather than the complete picture, your user journey's will suffer.
If you work for a company that can afford an Episerver license, the website will have a purpose. The aim of the site might be to sell a product, promote the company, get sales leads, etc... If you have a user experience where content editors are solely responsible for designing the user experience from within the CMS, your site won't have good user journey's, it's as simple as that. As any good UX designer will tell you, a good website design comes from research and stats. A successful project is one where you can define what the aims of your website are and then create designs that allow your users to be able to do whatever your objectives are in a simple, easy and intuitive way.
You may want a user to buy something, sign-up for a newsletter, visit a certain promotional page etc... This simplified journey won't be possible if your content editors have the flexibility to change any element on any page, however they see fit. That well thought out user journey to help improve the sales process will get lost as someone starts re-organising blocks one day to 'spice things up'.
Content editors will often work on a page-by-page basis. Over time it is very easy to forget the bigger picture. They might not have even been included in the original project kick-off process and UX conversations. Having a website that is completely designed from blocks will increase the chances that after a few weeks of content editors moving things around, your user journey's will be lost.
Next up, we'll discuss the problem in terms of a content editor. Most organizations are understaffed and people have limited time to do things. On a new project, if the content/marketing team need to write 1000 content pages then they will want to do this in the quickest way possible. When you work with Episerver, the quickest way for content editors to add content is to give them pre-set templates. On most websites, most pages will look similar to give that familiar style for site visitors. The easiest way for content editors to get this standardization is to use specific page templates. If on every page they have to build it themselves using 5-10 blocks, the time it will take them to create one page will double. Also, the chances that pages look familiar will be slim to none!
If you design a system where creating a page within the CMS feels too tedious, you will quickly learn about it from the content editors. During the initial project kick-off meeting, content editors might think they want one single generic template and 300 blocks. However, when confronted with a massive list of 300 components there will be problems. Editors will soon forget what each block does. They will also find it long-winded to create pages as they will have to jump between a lot of screens to get the job done. When this happens, editors usually get pissed off and moan about how clunky the CMS is to create a page.
The most frustrating part for a developer is that it was often the editors who asked for the site to be built that way. They often ignore some good advice and then in the end, blame the CMS for being crap! Before you think about going down a block-only approach, to make your life easier, I recommend showing the marketing team this article. Maybe create a proof-of-concept so they can experience what life would be like.
If you're anything like me, you will care about creating good quality solutions. Any good software developer will understand the DRY principle and will know, less code is better. When you work with blocks only, you will end up writing more code than you would in a more classic fixed template approach. Creating too many blocks will increase development effort and the amount of QA time that will be required. If you build a website with a block only mentality, how do you get sign-off before you go live? Each block will require a controller and a view model. Each block will need to be tested on its own, isolated on a page. Each block will also need to be tested in conjunction with other blocks. The more blocks, the more rendering permutations. Testing a block in one location is simple enough, however, it takes more time to test blocks within other blocks. It's easy for the developers to create 300 components in isolation, but does that mean it will work when they are all thrown together? In the real world, to have confidence that something works you need to be able to visualize it and compare it to the original spec.
When you think in terms of blocks alone things can get lost in the noise. When you have a huge block library, it's easy to forget what each one does. Many of these blocks might be combined more elegantly. When faced with a list of 300 things to pick from, content editors will likely use the same 5-10 blocks over and over again. It's a lot easier to identify re-usable components when you work with a handful of page designs, compared to a big flat list of components. Next up... the testing department.
Front-end developers can also get frustrated with too many blocks. As soon as editors start building pages and creating whacky permutations, a lot of CSS bugs will occur. It's all well and good trying to create a responsive design in fixed layouts, it is much harder in a block-only architecture! When content editors can arrange pages in ways the designer didn't even consider, you'll start to see CSS bugs come out in force. When people work with templates, it makes it easier for the frontend developer to test their work!
Are Blocks Bad... Definitely Not!
All of the above might sounds like blocks are a bad idea, but that is definitely not the case. Blocks are one of my favourite things about Episerver CMS. Blocks provide a degree of flexibility to a website that fixed templates have never been able to provide. The aim of this post is to warn you that going too far in one direction is a bad idea. Getting the balance between blocks and pages can be a delicate operation. Knowing how to do this takes time and practice and an Episerver expert will be able to help you with this. My suggestion is to be conservative when you first start designing things within Episerver. Favour prefixed templates with a selection of blocks as a first step. As the project progresses you can then split your templates into blocks when the pain points emerge. Happy Coding 🤘
