A lot of our clients are looking for both flexibility and simplicity, but those two — they just don’t go together. Flexibility adds complexity to the development and function of a CMS.
Why? Because you can either have flexible or you can have simple.
What it means for back-end users
When the system is flexible, there are a lot of decisions you have to make when building a page. At a minimum, it slows you down quite a bit. And in many cases, this variety of decisions that must be made allow the people operating in your CMS to make bad choices. Sometimes, very bad choices. For example, selecting two components that don’t go well together or components that aren’t a good fit for the intended content.
As our Senior Web Developer Andy Hebrank recently commented, “In general, we’ve had unfavorable experiences when we make the content entry system entirely flexible: It’s a buffet with too many choices (sometimes too much dessert) and overwhelming to the people trying to make the pages.”
And sometimes, people are going to choose to put things together in a way that’s just plain ugly.
The other option is to go simple. Simple can be good because it can make it easier for your content contributors to use. It also supports more consistent outcomes across the pages of your site and reduces the risk of content contributors making bad choices.
Build a CMS to suit your team
If you only have four different pieces or components to work with and they’re very different from each other, it’s pretty obvious what tool you need to communicate what you’re trying to do. But if you have 16, and most of them are similar, it’s easy to pick the wrong one.
Part of determining the level of flexibility or simplicity that’s right for your project is knowing your team. Can the people creating and managing content make (good) design decisions? If they can’t, then maybe you want to have those design decisions a little more firmly embedded in your templates.
For a dedicated, savvy team with a site that requires more complicated functionality, a higher level of flexibility may be the way to go!
What it means for the design
The other problem with flexibility is that the design has to make accommodations for it, both in the way you organize and build things inside the CMS and in the visual design.
For example, if you have six different components that can be put together in any order, then you need to look at 6×6 variations of how everything fits together to make sure nothing clashes, and that number can climb fast. Rich, exciting designs may have to be scaled down to something more generic and manageable, just to make sure all of the design options work together in any combination.
This is true for flexibility in back-end configurations as well. Sometimes people want all of the fields in a CMS entry form to be optional, which means that one front-end design has to accommodate all possible combinations of used and empty fields. Or people will want to make several presentational choices, such as the color of the background, images used as a texture, the styles of links, etc. The result is a content management system where dozens of tiny decisions need to be made for each component. Programming these options is time-consuming and testing all combinations is a real challenge, but that’s nothing compared to the labor all of these micro decisions create for people just trying to put content in a web page.
Is too much choice a bad thing?
If you find yourself making lots of design decisions inside the CMS, it’s worth asking yourself why the decisions are necessary. Do you really need all these choices? Or is it just a way of “keeping your options open,” putting off the hard work of decision-making until another day?
But that other day is coming soon. If you push those decisions off until it’s time to create content, it means you will be making the same decisions every time you create a new piece of content, and most of our clients have thousands of web pages. Make the decision once during CMS configuration, and your system is less flexible — but you don’t have to worry about those choices again.
Ok. You can have both.
Just not in the same place at the same time. The trick is to pick and choose where to deploy flexibility — to make sure it’s worth the extra effort. Because sometimes something really does need to be flexible. But other times, that flexibility gets designed and maintained out of anxiety, fear, or unwillingness to make a decision. That’s when flexibility ceases to be a useful tool and becomes a significant burden.
This is why we ask questions, and sometimes push back, when we are asked to make things more flexible. Flexibility that serves a specific content strategy purpose or design goal is great — in small doses. But flexibility for its own sake is often more trouble than it’s worth.
