Episerver projects are unique in nature compared to most other web projects. In today's guide, I'll cover some basic principles I recommend you follow when you start planning out your project. 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 Block
I've been working with a company very recently, who's original brief was to create everything as blocks. In theory, this may sound like a good idea. Writing everything as a block will give the marketing department the flexibility to do whatever they want without any intervention from the IT department. The marketing department within this company historically had issues getting the IT department to do work for them, so obviously when they go through the pitch process and get sold on the concepts of blocks, a lot of companies make a fatal mistake and think everything should be a block. 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 that I worked with who followed this process back-tracked as none of them were happy with the end result. Let me briefly explain why, in this scenario, the company thought that everything would be a block, so instead of following a normal web design process of identifying the website's templates, they decided to get their design agency to simply create a list of 300 components instead. The thinking behind this process was that it would give them the flexibility to do whatever they wanted. If you're starting a new website project and you're tempted to do this, DON'T!!! Following this approach will not only make your marketing department/content team unhappy, it will also make your life as a developer harder; read on to find out why.
Why Too Many Blocks Will Cause You Headaches!
Most projects I've worked on have a number of stakeholders, UX people, designers, developers, product owners, content editors. In this section, I'm going to explain why too many blocks will piss off all of these people. I was in the pub discussing this situation with a UX friend, who I should probably add isn't a familiar Episerver expert and he immediately got to why too many blocks will provide a bad user journey. If you design your website based on components instead of pages, your user journey's will suffer. If you work for a company who can afford an Episerver license, the website you're building will have a product or service to sell. If you have a website that is solely designed in blocks, then you 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, to sign-up to a newsletter, to visit a certain 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 and will forget the bigger picture. They might not have even been included in the original UX process, so having a website that is made up completely of blocks will have a very high chance 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. In the most websites, most pages will look similar and on most pages, all the content team wants to do is add content to the main content area. In order to do this, if on every page they have to add 5-10 blocks, the time it will take them to create one page will double. Trust me when I say this, when it takes people too long to create pages in Episerver, you will be the first person to hear about how shit the system is. On paper duing the initial project kick-off meeting, they might think they want one single generic template and 300 blocks, but when they try and create a page and they have a massive list of 300 components, people won't know what they do, how they should use them and then get pissed off and moan about how clunky it is to create a page.
The most frustrating part for a developer is usually they were the ones to ask for the site to be built like this in the first place... so before you think about going down a block only approach, to make your life easier, I recommend showing the marketing team this article. After all, it will only benefit them! Next, let's talk in terms of development. If you're anything like me, you will care about your work. Any good software developer will understand DRY 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 template approach. Too many blocks and your development time will also increase. Each block will require a controller and a view model. Each component will need to be tested. Testing a component in one location is simple enough, but how do you test your blocks within other blocks. After all, that's what your end page will be made up of. Also, when you think in terms of components, you will likely end up missing a lot of reusabilities. Let's say, for example, you have three different variations of a call to action control. When you have a big list of 3000 components, it's easy to miss, that these components could be rolled into a single block. 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. Too many blocks will also make the testing department's life harder. If you build a website with a block only mentality, how do you get sign-off before you go live?
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 don't have templates, you don't have that starting point to compare it against. Designers... the HTML designer will also get frustrated with too many blocks. As soon as people start building pages, a lot of CSS bugs will start to raise their heads. It's all well and good trying to create a responsive design on isolated components, but as soon as you throw them together and content editors can arrange pages in ways the designer didn't even consider, you'll start to see the CSS bugs come out in force. When people work with templates, it allows the designer to browse and devise the design.
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 favorite things about Episerver and they provide a degree of flexibility to a website in a way no other CMS system can. 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/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 start out and stick with templates with a selection of blocks as a first step. As the project progresses you can then split your templates into blocks, as you see fit.