By Janus Boye
Unreliable websites is a real problem. Whether it is a slow site, forms that doesn’t do the trick, or just broken links, it all influences the perception of your organisation.
Behind the scenes, things can also be unreliable. It might be editors struggling with a content model or developers constantly bug fixing. This could leave the editors feeling incompetent being unable to do simple tasks without help and the good developer probably won’t stay long if just faced with the routine of maintenance tasks.
Ondřej Polesný from Kontent.ai gave a refreshingly honest, helpful and technical presentation appropriately titled ‘how to protect your website’ back at the Web Summer Camp.
This quote stuck with me:
“Everybody knows it is not ideal, but nobody deals with it”
Do you also have work to be done to make your sites more reliable? Sharing is caring, so here’s a condensed version of his talk with his suggested five elements for you to consider.
Let’s jump into the list and Ondřej literally went content-first.
1. Streamline content model
Sharing inconvenient truths was an ingrained part of his presentation style and when it came to the content model, he bluntly said:
Your content model is hardly ever in a satisfactory shape
Sounds familiar?
His clear advice was to make content types as minimalistic as possible and he added that content types must be consistent among your content model.
Also, content types should not provide any freedom beyond what’s necessary. The less freedom you give, the less maintenance you will need to do!
2. Enforce tests for almost everything
Clearly a strong advocate for tests, Ondřej made the case for how tests can greatly improve the reliability of your website, while also improving the confidence of developers and significantly decreasing maintenance.
After a few slides with lines of code, he arrived at this thought-provoking quote:
If something breaks, don’t fix it! Ensure it won’t happen again first.
His actionable advice was to do unit testing for every testable unit, end-to-end test for every critical feature and then finally use automatic screenshot comparison for every styling change.
3. Set up a URL policy
Firstly, Ondrej pointed out that the source of truth for URLs is the website. This means that while your CMS of choice may hold that final piece of the URL commonly called the URL slugs, the CMS should never build full URLs for you or constraint you in any way.
In other words, let your CMS decide that last piece of your URL, e.g. that part in bold below:
https://www.boye-co.com/blog/2022/11/how-to-protect-your-website-from-editors-marketers-and-even-developers
but don’t let don't let the CMS build meaningless and unnecessary complex URLs, like this one:
https://www.boye-co.com/cs/ContentServer?pagename=HowToProtectYourWebsite
This has multiple problems, notable that any users use the website address (URL) to navigate, but also that it will create a ton of broken links when you at some point change your CMS.
The advice from Ondrej was to be careful about creating those URLs, centralise the composition of them, and make sure to regularly run broken links checks.
4. Improve code tooling
This one was clearly aimed at the more technical audience with the intention of making your developers both happier and more productive.
Ondrej had four recommendations on code tooling:
Use strong types (TypeScript) for both content and code
Use linting rules and enforce them on commit
Set up reliable CI (continuous integration) pipeline with no exceptions
Set up ground rules for code reviews
At Kontent.ai, they have a setup where every pull request that’s created (start of the pipeline) is automatically checked: That means – create a new build, run all available tests on it, when you’re ready, merge it into production. Also, no manual steps beyond what’s necessary (code reviews) and no possibility of going around the process.
As Ondrej said, that while it comes with an overhead (it takes a bit longer for new code to arrive in production), it already helped stop lots of code that were not yet production ready.
5. Clarify responsibilities
Finally, and really an evergreen for digital projects since the early days: Consider governance and who does what?
It can be this simple as Ondrej said:
Developers are in charge of code
Editors are in charge of content
Designers are in charge of graphics
Unfortunately, in many organisations it tends to be more complicated and the reality can be ugly as shown on this illustration where the arrows point in all directions to all stakeholders.
Learn more about how to protect your website
There’s more to be done on this topic, but probably this post based on Ondrej’s presentation already gave you a few to-dos.
You might also want to consider domain discovery (think brand protection) and decluttering your digital presence. Naturally the conversation on this continues in our peer groups and at our upcoming Boye conferences.
Finally, you can also download the slides (PDF)