If you’ve read any of our recent blog posts—and hopefully you have—you’ll already know much of what we’re going to cover in today’s post.
If you haven’t been keeping up to date with our weekly, original content (which is both insightful and entertaining!), let me first begin with a refresher regarding our perspective on content management here at the NP Group.
Our belief is that “content management” is much more than just managing a website. There are many software packages out there that can do this with some level of sophistication. We see content management as having multiple components.
First, the management of the actual content. This means organizing data types, storing data, and organizing it for analysis and distribution. As an example, let’s say you are maintaining an informational website where you are managing many types of “widgets.” You may have a content type defined for this type of data, a widget. That may mean fields that define what a widget is: name, description, prices, measurements, etc. The purpose of the content management component is so you can then add/edit/delete each widget and its associated data as necessary for your application.
The second necessary component manages the distribution and display of the content you are managing. That is where a Web CMS comes in.
The industry today has wrongly defined a “CMS” as a system that manages website content only. In fact, that is completely inaccurate. The Web is now just one of many different channels of content distribution. There are other ways that content is distributed, whether it be via applications or rich media content via other devices such as OTT (Apple TV, Roku, or similar).
Seeing how a website behaves in ways that are proprietary to the Web, it is important to have this layer of web content management on top of your content management system. One reason for this is to maintain the cleanliness and integrity of your content. Systems that are created solely for web use will store web-specific code within the data, such as HTML. But what if you eventually deliver that content elsewhere? How will you clean the content you have been storing for years?
Now, I know there are always doubters who think this is overkill, or who wonder why the popular web content management systems are so wrong or wouldn’t work for them.
The fact of the matter is, there are many appropriate applications for today’s most popular CMS platforms. Clearly, not every online destination needs a custom web content management system. If your application only delivers on the Web and you have no future considerations for other mediums, then WordPress or Drupal are entirely appropriate options, especially if you are a simple blog or informational site. If you are selling many SKUs or items in an e-commerce store that will only ever be on the Web, then surely you can trust Magento or other e-commerce packages.
However, if you are developing content of value with many distribution points, such as video, audio, images or likewise, it’s essential that you do not pigeonhole your content library within a platform designed specifically for the Web. The best way to ensure monetization of this type of content is to work to make distribution to many mediums possible.
Enter the CMS and WCMS marriage: a perfect balance of pure content management with web distribution management.
So, back to the original point of this post. If you are committed to pure content management for your library of content, you need a custom Web CMS component to power your own website or you need to customize an existing website to ingest and display content, which is possible as well.
Since we are, after all, a custom development shop, we’ll detail the former, highlighting the necessary components your system will need to manage your web presence.
We’ve spoken at length about our opinions regarding the future of web design. We believe that full flexibility of web content management comes via a “modular” approach. This means that rather than designing templates that comprise web pages, we focus on all the moving parts. Administrators can then use these parts to assemble pages.
We’ve done this successfully with both custom and off-the-shelf CMS platforms. Just to show we aren’t just WordPress haters, we actually have a modular plugin for use on WordPress.
The secret sauce with modular web content administration is to make the connection between the modular components and content as seamless as possible. This is best performed by allowing administrators to define what content populates what module, and the logic behind how it does that.
Here is an example.
If your primary content is video, you will have a tool to manage video content. In that tool, you may have fields such as titles, descriptions, meta data, and of course images and the video itself, all in different formats. All of this content is clean, without embedded code.
To display this data on your website, your Web CMS must allow you to select what videos display where based on either logic or personal input. In this example, if you have videos that are categorized, you can use a custom Web CMS to indicate that on X page, you want the 6 most recent (or most popular or highest rated) videos to fill a module that is 2 rows of 3 columns. Then, you may add a module underneath that to shows 9 videos from Y category, in another logical manner. Finally, maybe you have a single video module with one video you manually control.
This is how a modular approach benefits from a flexibility perspective—you can pick and choose what method of display occurs where on a page, and then input the precise video content that should be offered in that area.
Of course, a modular system would allow you to manage content that is always web-specific as well. So, you can augment your website with not only the clean content you organize in your primary CMS, but with web-specific content as well, all managed in your custom Web CMS. This combination allows the most power over your web distribution, while separating the proprietary content that is so valuable to your organization.
What are the alternatives to modules? The most popular method is to code front-end templates to automatically display content, but without having control over the logic of how the content is shown. Many websites were built this way for quite a few years, but the rigidity of this approach requires that website owners and content managers have a developer handy to change logical requirements.
This approach is also costly and inconvenient. Given the technology options available today, modular web CMS components are the most flexible tools to manage your Web CMS. Unfortunately, not many off-the-shelf platforms can perform this task, which is all the more reason to consider the custom Web CMS route.
One of the most requested features that is asked of us by any web administrator during a discovery or architecture session is the ability to preview content before publishing. Luckily, with the latest decoupled, custom Web CMS technologies, this isn’t always a difficult task. The reason is because when content and display are not comingled, it’s easier to populate HTML templates with content on the fly to show an effective preview.
Okay. Maybe I did make that sound just a bit easier than it is, but only because we have spent a lot of time thinking about how to make features like this work.
The truth is, preview is one of the most difficult concepts for most CMS platforms. Even those that already offer a preview have difficulty merging that capability with flexibility over placement, content display logic, etc. And to make it even more complicated, throw in the different resolutions that web content is consumed in: mobile, tablet, notebook, desktop, etc. Preview is not always easy to accomplish in all sizes.
If you are building a custom Web CMS, you must account for how you’ll accomplish this functionality. Publishers require the ability to see their content in a “live” environment to effectively edit and approve their posts. Not having this feature is almost a non-starter for the organizations that most require custom web CMS solutions.
One of the major reasons we recommend custom Web CMS solutions to customers is to create a single-screen solution for their internal teams. Our objective is to ensure that every employee can have just one window open with the same unified system, regardless of their role in the business. As such, system consolidation is a component of each custom Web CMS project that must be considered.
In looking at the metrics or statistics that content managers are most worried about, the same figures always present themselves: usage statistics, conversion statistics, and, based on the business at hand, perhaps more proprietary metrics.
Since so many businesses today are judging success based on metrics, shouldn’t your CMS have a dashboard to study these figures in real time?
Yet so many businesses have a website powered by a CMS platform that makes it hard to integrate tracking devices, let alone display the insights gathered by them. The fact is, the best performing businesses always have their own approaches to studying the metrics that matter to them. And because almost every partner or analytics company has the ability to access data via API connections, it’s easier than ever to pull statistics from multiple sources, normalize the data, and make comparisons that before were not possible.
When planning your Web CMS project, think about the statistics that most drive your decision-making process. Then think about how comparing them in new ways may assist you in gaining better insight into how your content is performing. From there, you can use that insight to refine your publishing process, whether it be the type of content you produce, how you produce it, or the specifics of the content: length, format, etc.
Oftentimes, clients don’t think about how to best deliver their web content in the most scalable and redundant way possible. Luckily, custom Web CMS platforms allow for a variety of options.
To understand why, you have to dig a little deeper into the architecture of how these platforms work. Most CMS platforms today are integrated systems. For example, WordPress and Drupal have their administrative portals and their front-end user experiences integrated into one codebase. Remember, “themes” are not decoupled, folks!
Because these are integrated, scaling can be a challenge. It is hard to load balance a system where a connection to a database is required for any page to work.
Sure, there are plugins for WordPress, for example, that allow for the caching of pages. But still, eventually with enough scale, you will have problems. This is where a decoupled architecture makes the most sense. When decoupling, you have your administrative tools and logic completely separated from the front-end user experience. This means you have more possibilities in terms of scaling your application.
Without going into too much detail, some of the options revolve around the fact that your new front-end can be powered by API connectivity to your CMS. API calls are easier to cache and scale, and the front-end can be hosted a variety of ways. Another possibility is outputting flat files to a CDN platform such as Amazon S3. This process ensures a high level of security, lightning-fast delivery, and less bandwidth costs.
The topic of scaling can be a blog post of its own. In fact, we already wrote one on flat-file distribution. The point I’m trying to make is that with a headless or decoupled system, there are more options available to you, which is comforting if you are preparing an application that you expect to grow over time.
By no means is this the last essential component. Honestly, everyone should treat security as priority numero uno. One of the overall benefits to building a custom Web CMS is that you can secure it in ways above and beyond industry standard.
Obviously, decoupling allows you to secure your CMS unlike any off-the-shelf software can do. You can literally lock your CMS installation on a server in a closet and shield it from the world if you wanted to. We’ve actually had customers do that.
But it’s more likely you would restrict access to your CMS by IP address or other firewalls. Perhaps, as mentioned above, you’d deliver the site via flat files on a CDN—not just easy to scale, but extremely secure.
The fact is, no matter what steps you take, an integrated WCMS such as the examples above can never be truly secure because the database that powers the administrative portal is shared by the front-end website experience. This means that you’ll never be able to be fully confident that your core CMS, plugins, and themes are all hardened enough to protect against intrusion without decoupling.
During the discovery and architecture phase of your CMS installation, plan on discussing how important security is to your company. Debate the types of intrusions that could happen and what the result of such an intrusion would be. Then assign risk profiles to the various platforms available to you.
Are you interested in as little risk as possible? Then a custom web CMS platform is definitely the right pathway. However, if security is not a major concern, then there are many other possible directions you can take with your project.
This post was really meant to be a primer into the concept of the Web CMS being a separate component of a true content management platform. With the evolution of content consumption online today, the Web is becoming (if it isn’t already) simply one of many venues to distribute content. But it’s still a complicated medium that requires its own set of rules and tools to manage.
Your homework? To carefully consider the concept of how you keep your valuable collection of content clean of web-specific code and manipulations, yet continue to manage web distribution at a high-level. Solving this challenge will place you ahead of the pack and leave you free to worry about creating great content, not continuously looking for better ways to manage it.