The question of the current status of the evolving role of Web CMS was the key takeaway from my recent conference trip to Philadelphia. This article summarizes my presentation that touched the topic from one angle. Also in the end of the article I will summarize the discussions around the matter during the conference.
As a background to the conference, the J. Boye seminars are well known in Europe as being one of the best-organized seminars for web and intranet professionals. This past seminar in Philadelphia was slightly smaller than their events in Denmark, but the presentations and the atmosphere provided the same high level of professionalism. The seminar had a few different tracks on mobile development, social media concepts, intranet management and web content management.
My role in this conference was to be the first speaker on the web content management track, and I used the opportunity to discuss the differences between Web CMSs and web development frameworks.
My presentation’s topic: Web CMS vs. frameworks – different approaches.
My presentation starts by explaining the one of the main challenges of today: the creation of a “unified customer experience”. The main point stands that even though we would like to create a unified experience, the realities of technology limit our possibilities – either by making the project really complicated or expensive. The presentation then outlines the four different approaches to face the challenge.
The first approach is actually a counter-argument against a unified experience, because not every business needs a unified strategy, and sometimes having a more agile multi-brand strategy makes more sense. Also this strategy of having multiple service brands can be very mobile-friendly in the sense that it is easier to do small applications when each of the service brands is a very specialized service. For many organizations this kind of web strategy is impossible, but for those who can use this approach, it can enable the usage of best-of-breed systems with minimum management costs and complexity.
The second approach is also not a technological solution, but purely a user experience solution. By unifying the user interfaces of each different service (eg. website, eCommerce, booking system) it is possible to use a best-of-breed system to run each service area. This often requires also a shared main navigation, which can be managed as static html or with the CMS. The main challenges of this approach relate to creation of liftups, or creation of automatic suggestions. Both can be done, but with different systems in place each element is usually additional development work or manual cross-linking. The benefit of this approach is that it often enables the creation of unified customer experience using best-of-breed systems – and those systems can be either best-in-class or the most cost-effective choices available. I would actually argue that this approach is most commonly used when complex custom applications need to be somehow “faked” to appear as being a natural part of the main website.
The third approach is one where most custom applications are built on top of a Web CMS. This approach is the most traditional one, and is still widely used. Building on top of CMS offers a lot of benefits especially if the CMS has a good model of separating content management from custom functionality – and to be honest some Web CMSs are quite good in compartmentalizing the custom applications from the rest of the system. But in general, the purpose of Web CMSs is not to be development platforms for custom applications – and therefore this approach should be used only when absolutely necessary.
Building on top of a CMS makes the most sense when the website has lot of content and custom application needs – and especially when that content needs a lot of updating by content producers. This is the scenario where Web CMS vendors like to talk about “web experience management” which means cross-linking content and functionality, automatic suggestions, and other clever cross-promotion methods. Usually this makes the most sense when there is a reasonably sized content editor team in place, which can “manage the experience”. The most typical challenges of this approach are related to difficulties in updating the CMS components or making continues improvements to the system. The harsh reality is that any service that has a lot of content and lot of custom applications (which are built on top of system which wasn’t really designed to be a development platform) tends to become a quite heavy beast.
The fourth approach is to build the web presence on top of some web development framework (eg. Django, Symfony). This approach is quite close to building your custom website and CMS, but is much more practical today than it used to be. Frameworks enable a more cost-effective building of custom applications than most CMSs and many frameworks also come with tools that enable limited content management capabilities. This approach makes sense especially when building a web presence where custom applications have a big role, and the content is either limited in size or if the content is pulled from back-end systems. This reality is actually quite common in many large commercial sites where most of the content is pulled from back-end databases, and usually that content is also managed primarily using those back-end systems.
The main message of my presentation was that there are several smart ways to build a web presence today – even though the target would be to build a unified customer experience.
Currently the Web CMS vendors are promoting heavily the “web experience management” agenda, which usually refers to building every area of the web presence on top of their Web CMS product. This approach certainly is valid in some cases, but it certainly is not the only approach.
It was nice to see that the other seminar presentations touched the same topic in Philadelphia, and there were actually very interesting discussions about the possibly shrinking role of Web CMSs. This seemed to be the consensus especially in the context of the need to build websites that can adapt to different mobile devices which make many Web CMS features somewhat less useful (eg. wysiwyg editor, inline editing, easy template control).
It’s clear the requirements for Web CMS are actually shrinking from a content editor’s point of view – or they are at least changing. The requirements used to be more about the presentation, but today, especially content producers (or content strategists as they are called today more often) demand the CMS to be more about structural content management.
The mobile track of the seminar also was interesting to follow since so many of the subjects were about issues that really didn’t have much to do with Web CMSs. Building a great user experience for mobile devices, and for example making it perform fast, are just few examples of things that are much more about just smart design and technical production than areas where Web CMSs could offer much help.
The role of the Web CMS is not disappearing alltogether, but certainly in many cases the Web CMS is becoming just a small piece of the puzzle. We still need content management – we just might not need it to be the central piece of our web platform.