What is a Content Management System (CMS)?

My world is very well steeped in Content Management System (CMS) usage being the norm, but recent conversations have illuminated that there are many people charged with putting together a website, that haven't been given the opportunity to learn how a CMS would make for a cheaper more maintainable site.

To be clear, I'm not suggesting that every website should built with a Content Management System. Probably not even a majority of them.

After explaining a little bit about what a CMS is, and does, I want to talk through some of the most popular website types and which ones benefit from the use of a CMS.

Web site Roles

Let's start by defining who interacts with a website, during a normal life-cycle.

The "End User" or "The Audience"

The person finding value in the existence of the website. Whether the person is simply consuming content, or helping to contribute it, the end user is who the site is being made for.

The Stakeholder (Site Administrator)

The person who identifies the need or opportunity being addressed by a website. This can also be the person charged with the task of creating a website within an organization. In this article I am also including the person in charge of changing and updating content on the website. Which could be one person... or thousands of people.

The Developer

The person that takes the stakeholder's idea and converts it to a website. I'm using the term "developer" here more generically, this would include designers, etc.

What is a Content Management System?

A Content Management System is generally defined as a system that allows the management of digital content, usually on a website, often by more than one person. Practically speaking, what this means is that if content on a website needs to change, be it every minute, or once a month, the "Site Administrator" has the control to be able to log in to an administrative site, and make updates that are then reflected on the user facing website(s).

Going through some website "types" will also help communicate more features of a CMS. So let's look at those.

Website Types

I am going to go over what I consider to be major types of web sites. This is very much an over generalization of all websites, but I think it will work well for describing the impact a CMS has on these different types (if any impact at all).

A website, in the end as its presented to the user, is usually nothing more than HTML, CSS, and Javascript. Programming languages, and what it creates (libraries, frameworks, Content Management Systems, etc) are all tools, that in the end, just produce HTML, etc. A programming language is like a super fast web page editing assistant.

Brochure Site (Static)

I'm going to classify this as any kind of website that is generally just informational, in the old days this might be replaced with a "brochure" in paper form. I am describing this kind of website as one that has a finite (limited) number of pages; it could be just one page. Branding is usually a major purpose of the site.

Some examples of this type might be a small business, like a dentist office, or landscape company. Or perhaps a restaurant, who's primary purpose is to provide a menu and contact information. In the world of software (which I live), a singe page (Brochure) site is often used to create some identity and description of a particular software project.  It may show some screenshots, and a link to GitHub. 

I think you get the drift.

How would this kind of site use a CMS? Or would it need one at all? In my opinion the answer is usually that it does not need one. Content doesn't often change, and when it does, the changes are minimal. These websites, because they are only a few pages, are usually just static HTML, CSS, and JavaScript files. Meaning there isn't a server language (PHP, Ruby, .NET) generating the markup based variable factors like a database (or some persistence layer).

The best person to contract with in this situation is a Graphic Designer. A good Web Designer can put together graphics and usually has enough knowledge to construct a website's markup, style and animation. 

Of course, a CMS CAN be used in this scenario (and often does). Perhaps a designer or developer has so much experience in a given CMS that it's quicker for them to do this way. Or some element of the site requires data retention in a persistence layer (meaning information collected needs to be retained after the user leaves the page, like in a database). There are drawbacks to adding the weight of a CMS if one isn't actually needed. Adding a framework of server side code usually has many dependencies. The server will require a certain amount of capacity as it relates to memory, CPU and storage. New releases of software dependencies (like the CMS itself) require maintenance to the site, perhaps as a security measure. Simply put, things are are generally more complicated than they need to be. Like buying an RV for the use of only driving it around the block once a day.

I also want to mention, and dispell any fear, that deciding to use a static web site limits what the site can handle in terms of traffic (number of page views), in fact, a site without a server side programming language will scale better in every way.

Dynamic Content Driven Application

This category encompasses sites that small or large, rely on content that updates on a regular basis. This is the site you visit more than once. It can be a blog, a store, a forum, or anything in between. It can be maintained by one administrator, or thousands of anonymous users.

The basic need for this kind of site is the same. Content providers need the ability to update the site at will. And let's face it, contacting a developer or site builder every time a change is needed is terribly inconvenient, usually time consuming, and most likely expensive.

This is what the CMS was created for. Anyone with login credentials can make changes to the site. The scope of what can be changed, and what can not be changed is defined during the building of the site, of which you are most likely going to use a developer for. Leveraging a CMS, a developer and site administrator need to work together to determine what should be stored in a database (because it is something that changes) and what should be developed or created statically... like a brochure site.

A simple blog may only need the ability to add and update articles. However, most of the site doesn't change often. Other sites by have many different types of content; maybe an article, a product, a rotating banner, quote or testimonial. Changeable elements can even include more foundational elements like the color of page headers, or whether the side bar displays on the left or right, or if it displays at all. These are the main things to consider during the development phase of the site.

So if a CMS has the capability to enable an administrator to change any element on the site, why not make everything on the site changeable? The answer is cost, and ease of use. While it might be great to have the ability to change lots of stuff on the site, it may not be in the site administrator's best interest. The more variable elements on a site, the more opportunities there are for problems resulting from the being used in an unintended way. This is multiplied further by the number of people editing the site. You can't predict what crazy things your team mate or end user will try to do (looking at you, MySpace).

Dynamic Data Driven Applications

Some might include this type of site in the previous type described, Dynamic Content Driven sites. I'm separating it out because I want to highlight some important times when complex sites may not be best served by a CMS.

It is difficult to define using a particular term or phrase. Data Driven applications may be sites where data is collected not for the purpose of reading as-is, but rather in relationship to other pieces of data that collectively convey meaning. Applications in this category can also be ones that have a highly specific purpose, providing specific functionality.

Maybe an example?

Let's say we are creating a to-do app, because quite frankly, we always need more of those. Our app is more or less one page, with some "modal" windows for taking certain action or auxiliary information. It consists of a list of items that have a description, a tag (like priority) and a due date. This site is highly dynamic and is not like a brochure site in any way. But it also isn't about organizing a variety of content displayed across a website with different sections, menus, sidebars and landing pages. Our to-do app is simple in that it has functionality for a very specific purpose, but complicated in that it needs to do everything a user needs on just one page.

Given this example, it probably isn't necessary to implement a full framework consisting of many capabilities and features like a CMS. It might be like carrying a Swiss army knife with a hundred tools on it, when the only thing it will be used for is cutting rope. The Swiss army knife will cut rope nicely, and if you happen to get a hangnail, it can help take care of that too. In this way you can also implement a one page app using a CMS with great results, but all that unused functionality may require more hardware to host the site on, and more code updates to handle security vulnerabilities as discovered in one of the many provided features, etc.

It is less about the size or complexity of a site, and more about what it is going to be used for. If your site is publishing content, there is a lot to leverage in a CMS. But a one page app might be better served by a framework designed to assist a Developer in managing a custom database for a highly specific purpose.

Service Based / Headless

The last "type" I want to review is what we developers call a "headless" or "decoupled" site. This means the site has no "front-end" where content displayed to users. Instead it houses information in a central location where other auxiliary systems can refer to it as needed.

Bringing back the To-do app example. Maybe the intent is not to have a to-do website at all, but instead a to-do iPhone app. So all requests to the website will be made by apps, not humans. This means that the website will be used as a "service" disseminating information in a terse unreadable format that communicates efficiently with an iPhone app.

As it relates to a CMS, it may or may not be the best fit. Like discussed above, it depends on what kind of content is being distributed, and how (or if) someone will be administering information at the server level. If the purpose of the site is to merely be the "glue" that binds multiple devices, and saves user generated information, then CMS may be overkill.

The Blurred Line

I've tried to outline various common scenarios and whether a CMS would be the appropriate tool to use. But there are many other factors and exceptions to these rules, the most important factor being developer expertise. The developer you are working with needs to be comfortable is whatever solution is selected.

To make matters even more complicated, most Content Management Systems are working to offer options for building lean data driven apps. Likewise, frameworks that are often used for lean data driven apps are working to provide more CMS like features to capture that market.

Conclusion

The summary is this: You should use whatever tool saves the most time and money while offering a high quality solution that performs well. If you are managing a large site with lots of information and using static HTML web pages, you should consider the many ways life can be made easier by implementing a CMS.