Do you really need a CMS?
Escaping the dynamic content pitfalls
Building great and unique websites/web apps where the content is managed by the Client comes with many challenges. With the now de-facto responsive website allowing for user-entered content is even harder.
For some projects, the benefits a CMS can bring outweighs these extra complexities, but I’ve seen cases where they’ve brought nothing but pain.
I often refer to the below chart. I made this as a joke, but I think it illustrates the case. You cannot have a site that is 1: fully content managed, 2: good looking and 3: quick to build (cheap). You can have any two of the above, but not three.
Step 1: Planning
This is where you can save yourself the most pain.
Often a site is sold as “fully CMS’ed” when in most cases the client just wants to be able to post news and update contact details. For these cases there’s a lot of options out there. Static site generators and even website-as-a-service providers like squarespace.
Premature optimisation is the root of all evil.
“CMS’ing” all the things “just in case” is asking for trouble. Unless the project is very large and will have constant active maintenance there is no way the site won’t look trashed after a few months in the clients hands.
Here’s how it goes: The designer creates a beautiful design that the developer tries their best to replicate and wire up before finally the client absolutely wrecks it with ill-fitting content.
This isn’t the client’s fault! It’s the developers job to make sure the client can’t break anything, but still allow them enough power to do their job.
What is the core content? What does the site actually need to say and do? The less content that is dynamic, the less margin there is for error. With each thing you decide needs to be content managed there comes a tax of time, effort and aesthetics.
Spend time thinking of the admin dashboard. We put so much thought into the end user’s experience, but the content managers are often forgotten.
This is also the case for many CMS platforms out there. They provide docs for the developers and serve the visitors well, but the content managers often have to deal with hellish, slow and confusing dashboards.
Building a custom dashboard isn’t always feasible, but make sure you pick the right tool for the job and spend some time in the client’s shoes. If it’s easy and painless to manage the content then there will be less problems and less support needed.
Step 2: Design vs Content
This is one that i feel very strongly about. Making the design elements of the build amendable is very risky and should be avoided in most cases.
What do i mean by design elements? Anything that isn’t core content. Background images, colours, branding. Things that make the site unique!
Let’s look at an example.
A full-page hero section with a background video or image. The first things people see when they land on the website.
A typical line of reasoning might be “The client might want to change this at some point in the future..”
Design imagery and videos should go through a designer. The CMS can crop, scale and compress images, but it can’t reason about colour tones, focus points and whether the image is right for the brand. These things need to be considered by a professional. After all, this is the face of the website!
Unless the client has an in-house web team with a designer they should have to come to you for these changes. That’s what SLA’s are for.
A possible middle ground here could be to provide a selection of pre-made approved images and let the client change the current one from a select list whenever they want.
With this in mind, here’s some advise on various kinds of content and how you can bullet proof them.
Step 3: Bulletproofing inputs
Okay. So you’ve decided what content needs to be dynamic. There’s probably going to be a few page templates each with various types of content. What does the authoring experience look like for the user?
Blocks!
Instead of providing a giant all-in-one solution, my favourite approach is breaking up your content into blocks. An “image block”, a “list block”, an “article block” etc that the Client can combine, mix and match to form pages. This way you can build each block one by one and make sure they work well responsively, and that no matter what content is added in, it’s not going to break.
Implementing this depends on the CMS. Perch comes with this built-in, which is partly why I favour this for small/medium projects.
Give the client enough power to do the job, but not enough to wreck stuff.
Which brings me to..
“Rich Text” editors
Remember myspace? Giving the client a full-featured WYSIWYG editor will eventually turn any website into a myspace page.
Absolute nightmares. A lot of very clever people have worked on these for years and have all failed to produce a portable solution. Sure, they kind-of work, but then suddenly there’s a <ul> inside a <h2> and all hell breaks loose.
Again, I’m not blaming the client here. I can barely work these myself, and i do this for a living!
I would advise against these, go for a markdown editor instead. If you really have to use them, make sure you don’t use the default settings. Strip them right back, apply your own stylesheet to the editor and for the love of god, make sure paste doesn’t keep formatting.
Other alternatives: Markdown editors, content blocks.
Text fields (text only)
These are probably the easiest types of content to control. They typically come in single or multiline formats.
You can set character limits, although responsive designs means the width of the field will vary, so most often this isn’t good enough.
Below is something often used for non-critical copy. The text width is limited to the width of the parent container, and the overflowing content replaced with “…”
.trimmed {
overflow: hidden;
white-space: nowrap;
text-overflow: ellipsis;
}
Image fields
Image fields are fairly easy to control. If the image can be applied using background-image then background-size: cover should ensure it looks OK across all screen sizes.
Many CMS solutions provide built-in solutions for serving responsive images. If yours doesn’t, the below example could get you started:
<article>
<style scoped>
.story--<cms:field id="title" urlify="true" /> {
background-image:url(<cms:field id="media-s" />);
}
@media only screen and (min-width: 640px) {
.story--<cms:field id="title" urlify="true" /> {
background-image:url(<cms:field id="media-m" />)
}
}
@media only screen and (min-width: 1366px) {
.story--<cms:field id="title" urlify="true" /> {
background-image:url(<cms:field id="media-l" />)
}
}
@media only screen and (min-width: 1920px) {
.story--<cms:field id="title" urlify="true" /> {
background-image:url(<cms:field id="media-xl" />)
}
}
</style> <div class="story story--<cms:field id="title" urlify="true"/>">
<!-- content -->
</div></article>
The inline style tag is scoped, which means it will only affect elements within the parent container, in this case the article. This tag is ignored in older browsers, but since our class selector will be unique this shouldn’t matter. With web components, scoped and inline styles will become more common, so even though it feels wrong, i wouldn’t worry about it at this point.
For inline images, use the CMS to generate scaled versions of these and some responsive image solution to present these.
Summary
We’re at a point now where the web is maturing, and so expectations are up on all fronts. Many Clients will expect to be able to magically change every element of the site, so your job is to explain to them that — unless they have a full in-house web team — this is a terrible idea.
Give them enough control for them to do their job, but not break the site.
If you do a good job of this then the site will have a long life without deterioration, and the Client will thank you in the long run.
- Pick the right tool for the job! Static site generators are awesome!
- Spend time on the dashboard. Make it easy for the user to use.
- Don’t CMS everything! Think about purpose.
- Don’t CMS the “design elements”, the soul of the site, the branding!
- Bulletproof inputs! No WYSIWYG’s unless there’s a gun to your head.
EDIT 29/12: As Joel Drapper pointed out in the comments, there may be other reasons why a CMS is used like structured contents and linked data that would be harder to implement manually. Take this into account when planning and deciding what tool to use.
