On the 13th of December, we held our first CMS Summit. We surveyed to get some insight into this topic internally. When I designed this survey, I wanted the answers to provide us some oversight that we currently don't have yet - at least in a structured way. In order to get the full benefit of this, without reducing the complexity of a nuanced answer too much, I decided to go for scaled questions, divided into questions about experience and questions about opinions. Both are valuable to have, but the way we relate to them as individuals and as an organisation might vary. These were the questions I asked:
Questions about Experience; These questions were answered on a scale from "never" to "always", 1 - 10:
"In your day-to-day work, how affected are you by CMS' in general?"
"How many clients ask for CMS capabilities in some form?"
"How often do you think that using a CMS would be a good fit for a project?"
"What CMS have you developed with/for before?"
Questions about Opinions; These questions were answered on a scale from "disagree" to "agree":
"The choice of CMS affects the quality of the output of the project."
"The choice of CMS should be determined by the needs of the project / client."
"The choice of CMS affects my individual DX."
Without further ado, let's look at how we've answered these:
In your day-to-day work, how affected are you by CMS' in general?
This was one of the earliest questions. It is intended to find out, how much of what we do on a regular basis is affected by any form of CMS. From what we can see, this subject does affect the overwhelming majority of us regularly, in different ways.
How many clients ask for CMS capabilities in some form?
From this, we can conclude that the majority of clients have this subject on their minds. We asked this question specifically with regard to "CMS capabilities" because while some clients undoubtedly have specific wishes for specific CMS in mind, others just express their desire to change some content on their website. And for that, we don't necessarily have to rely on an entire CMS.
How often do you think that using a CMS would be a good fit for a project?
These answers reveal some of the benefits of using a CMS. Not only do they bring utility, but they also have the potential to reduce complexity by limiting architectural or programmatic choices from the beginning. This can sometimes accelerate the development process!
Here we asked specifically about CMS, not "CMS capabilities". In order to get more insight, it would have been a good idea to ask for differentiation between these things. How do we know that a project is a good fit for a CMS? But we didn't answer that question this time around.
What CMS have you developed with/for before?
We do not all have the same level of experience with all CMS. The choice of CMS is a big variable for us. Let's look at some of the answers to questions relating to CMS choice:
The choice of CMS affects the quality of the output of the project.
Here we can consider consensus on this question. We all agree that the quality of the output is determined by the CMS itself, with varying opinions on how strongly it does so. And if it does, shouldn't the CMS be mostly determined by the project itself?
The choice of the CMS should be determined by the needs of the project / client.
For this question, we didn't differentiate between client needs and project needs, which can often differ or even be diametrically opposed. Our clients may have specific needs that may be at odds with the project's needs. In which case, the CMS has the difficult task of bridging this gap. Success with a CMS is strongly determined by the capabilities of the individuals using it, and we believe that the choice of the CMS should be determined by this.
The choice of the CMS affects my individual DX (Developer Experience)
An interesting followup question would have been whether the individual DX should also affect the choice of the CMS. And what would be more important - the needs of the client/project, or the developers?
This is a fascinating question because the client/developer relationship is often affected by the technological constraints and/or freedoms thereof. It would be interesting to find out where we see more success and more high-quality output: by adapting the choice of CMS to our individual needs or to the needs of the project/client?
We're looking forward to adapting and asking these questions again when some time has passed. As experiences change, the ecosystems shifts and more projects and clients refine our understanding of CMS in these processes, so will our relationship to CMS.
We learned some key takeaways that we processed during the CMS Summit and are continuing to do so:
Most clients want CMS capabilities.
CMS can sometimes make our lives easier.
Not all CMS are created equal, so...
... the choice of CMS needs to be carefully considered.