What we learned at the Belgian Craft CMS Meetup

First up was one of our own: Nick Denys! Nick took us through user experience in the back end. When we build a website, we always put a lot of work into the front end. We do research, we test our designs with users and we apply all 4 pillars of UX: value, function, usability and impression. But why wouldn’t you also do the same for the back end? We don’t just deliver a website, it includes a CMS that your client has to work with. That CMS needs to be self explanatory: if a client can’t use it, it’s not worth much.

So how do we achieve that, how do we create a CMS that a client can use? First you have to get to know your clients, understand who they are and what they know. Who will work with the CMS? Are they tech savvy? What do they want to do with it? Listen to their wants, but also predict their needs. They might not even realise what they want until they use it in real life, that’s why we always schedule demos!

Another solution is to set limits. Always assume your client will break something, which you can’t prevent, but you can prepare for it. For example by creating user roles: an editor can’t delete anything. Disable what your client doesn’t need and try to facilitate them as much as you can. Separate your asset volumes and folders, so when a client needs to insert an icon, they can’t select a picture.

Lastly Nick explained how clear labels help your client, as well as a clear field layout. It will feel more intuitive for a client if a title is positioned above the text. You can add extra help by providing context to your fields. But the basis for all this is to create a CMS manual, specifically for each client. This is the best way to make sure they understand the CMS and can work with it without problems.

Next up was Jan D’hollander from Teamleader. He talked with us about how you can create a modern dev environment with Docker. But before we could start this journey, he defined what makes a good dev environment: it should save you time and needs to be easy to use. If it takes a lot of time to get it up and running, it’s not good enough.

Jan took the audience back to 2015, when he was using MAMP PRO. For that time it was pretty wild, it got all you needed to run Craft: web service, PHP, MySQL… So why did he change? MAMP PRO had issues with versioning of multiple projects. Issues would arise if you were not on the right php version. So maybe it works on my device, but not on yours. Or it works locally, but not on the server when you deploy it. He started looking for other options, and one that stood out was Docker.

Docker makes use of containers, which offers multiple benefits. There is no influence from your own pc on the product. Every service is containerised, so you don't need to install newer versions on your computer. It’s shareable across different OS devices. But Docker also has one big downside: it takes hard work and a lot of time to learn how to use it.

Enter DDEV! DDEV is open source software that is specifically designed for local php development. It’s a layer you can add to Docker, containing a lot of tools that you can use without knowing the ins and outs of Docker itself. It’s easy to add this as a small layer to your local Craft setup, making Docker easier to use. Jan showed us a little setup and challenged our audience to try it out at home.

“DDEV is a layer you can add to Docker, containing a lot of tools that you can use without knowing the ins and outs of Docker itself.”

Our last speaker of the night was Michael Thomas from Percipio. He explained how they integrate atomic design in a Craft CMS workflow. Atomic design, a methodology created by Brad Frost on which a lot of companies - including us - derived their component based approach on. Michael made sure to note that atomic design is not a linear process. Don’t design in isolation, use it as a mental model. It also improves collaboration with designers, since they use the same component names.

Michael describes how they use these principles in Craft, by implementing a template structure setup. They create a folder for every principle, and every subfolder has its own name e.g. ‘buttons’. Every atom used has a description on what properties they can have, and contains a macro that receives an object via which these properties can be passed. They insist on using the same structure to build up their atoms. This way everyone understands it and new employees can be easily trained.

"Keep your molecules simple and reusable. If they need structural changes, just create a new version of the molecule."

He also shared some of their best practices with us. They try to avoid having too much logic in a file: it needs to be clear what the function is of your molecule. Keep it simple and reusable, if it needs ‘if-else’ states or other structural changes, just create a new version of the molecule. By doing this, they avoid having merge conflicts. But that’s not the only benefit. By using this system, everyone is on the same page and speaks the same language. Onboarding is easier and they reduce maintenance time.

And with that, this interesting evening almost came to an end. Our fantastic speakers definitely gave our guests something to talk about afterwards. We had a few drinks and exchanged ideas and experiences. We’re already looking forward to the next Belgian Craft CMS meetup!