A Short, Semi-Accurate History of Web Content Management

Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained […] infancy is perpetual. Those who cannot remember the past are condemned to repeat it. George Santayana

To understand where we are going in Web Content Management, we must first understand how we got to where we are now. Let’s embark on a semi-accurate and mildly satirical journey through the history of Web Content Management.

In the Beginning…

In the beginning, the web developer created raw HTML without form or process and saw it was bad.

Incantations such as FrontPage and Dreamweaver could produce elegant pages from arcane HTML tags, but code and content were inexorably mixed any changes to words or images required developer support.

Developers grew tired of marketing buzzing on about customer journeys, content velocity, and interactions and decided something must be done to provide separation between content and code.

The Expanse of XML

And the web developer said, “Let there be XML in the breadth of the codebase to distinguish between the content and the code and let the XML be called content and have a system for marketers to manage it so I don’t have to”. Along came enterprise software vendors with solutions to convert large piles of cash into maintainable websites.

The web developer wrote code in XSLT and marketers wrote content in XML and they saw it was bad.

Content and code were theoretically separate, but new features and changes still required coordination between marketing and web developers and interactive web applications and marketing websites were divided by a chasm deeper than the darkest trenches of the seas.

Rise of the Web Content Frameworks

Lamenting the disconnect between web apps and websites, the web developer said “if only I could have one system that would join a content management system and web application framework as one, then it would finally be good”. And came Drupal, Adobe Experience Manager, and Sitecore which provided all of the features the marketer and web developer wanted out of the box. 

Lamentably, the marketer had eaten from the tree of design and saw that the website was naked. The web developer extended the out of the box features and soon saw it was bad.

Upgrades were excruciating and due to the entanglement of custom and framework code, seemingly small changes required many hours and significant costs.

Single Page Everything

Away in the mystic land of Silicon Valley, the one true prophet of technology, introduced the one true Single Page Application framework React. Shortly thereafter, the other one true prophet of technology introduced Angular which is also the one true framework for Single Page Applications. 

These Single Page Applications enabled the web developer to create websites that avoid the one thing that bothers users more than anything else, page reloads and so the marketer and web developer decided to rebuild all of their sites so they would finally be good.

The web developer rebuilt the site’s Single Page Apps and the marketer saw it was bad. No longer self-enabled, every change once again had to through a development release process. 

Let Them GET /cake.json

Storming the bastille of the now-traditional CMS paradigm, a new cadre of headless CMS solutions fomented a revolution to overthrow the class system of static websites and dynamic CMS systems and replace it with an egalitarian, universal Content API.

Swept up in revolutionary fever, the web developer and the marketer again re-implemented half of the website on a new platform before realizing it was also bad. 

No longer able to leverage a base framework, the web developer had to reimplement the wheel, while the marketer struggled to understand the context of the content without visualizing it on a page with the form-based content authoring. Thus the cycle continued and the universe collapsed on itself in an explosion of budgets and technology debt when the web developer mentioned re-implementing with GraphQL.

Learning from the Past

Web Content Management is a discipline which takes a week to learn and a career to master. While at the simplest, it is just putting markup and binary assets on the internet, the inherent contradictions in needs, goals, and capabilities introduce tremendous challenges.

Based on my experience in this industry and many lessons learned I’ve come to the following conclusions:

• One-size-fits-all solutions are rarely completely right, most often the solution involves multiple approaches working together
• If choosing a one-size-fits-all solution, you must be clear on what you are giving up and ensure those compromises are worth the architectural simplification
• When defining the content structure, start with Authoring, not the experience being created. If you understand how content will go into the system and then how it will be exposed, you will understand the optimal approach to content
• The interrelation of code and content in HTML requires balancing the desire to create rich content with the technical debt, complexity, and brand consistency challenges this introduces

What’s your takeaway? Leave a comment below and let’s discuss!