Building a CMS implementation, teams focus on numerous deliverables – building the user journeys, crafting a beautiful and engaging design and user experience, building and testing editable pages and components, writing the perfect content to tell our story…then we launch – and we’re done, right?
Well, no. At Brainjocks, now Perficient, we’ve built our legacy on looking into the future of each project and teaching our clients not just how to manage content, but more so how to leverage the CMS as an asset that brings continuous value, learning and maturity to the marketing team.
In this article, we discuss what success of a CMS implementation should consider – from the marketing operations perspective.
The Importance of Marketing Ops
Marketers understand the need to reach the right person, at just the right time with the right message. Data collection and personalization go hand in hand with the strategy of crafting the message to the visitor’s unique needs based on interests and behaviors of the mark.
As engineers, we might not be so keen to recognize how complicated marketing is. Marketing involves numerous activities around strategy, planning, segmentation, budgeting, reporting, tracking – not to mention the hands on work of creating and delivering content assets and managing campaigns. Marketing operations people are marketers that focus on the delivery and effective measurement of marketing campaigns. Campaigns have to be designed to be measurable, and content and technology must unite in harmony to draw in the visitor, keep them engaged and record the relevant data.
And, like everyone else, marketing operations is under constant pressure from the business to increase efficiency and speed of output by implementing better processes and tooling.
CMS Gone “Wrong”
Why were content management systems created in the first place?
First and foremost, CMS systems are designed to reduce the need for coding websites from scratch – including reducing the need to ongoing technical support for changes to the content of the website once it’s built. Modern CMS system include much more – localization support, workflow, permissions and security, versioning, compliance – those features all play a role in building an operational model for marketing teams. However, when you are building a solution for CMS, always be aware of that primary purpose.
Let’s take a look at some of the ways that CMS implementations can miss the mark.
Unmanageable Content Management
Features and limitations of a CMS platform or poor design can lead delivery teams to create areas of the website that are more or less unmanageable. Some of these are simple and can be easily remedied – such as providing authors the ability to manage metadata and schema markup. Usually the difficulty centers around functional areas of the site such as search pages, navigation and forms, however this is also evident when functionality of the website requires integrations to third party content providers or other services.
The reason such experiences are crafted in a way that is not manageable is that when they have complex behaviors and user experience they are typically built into a monolithic component architecture. Monolithic components are components that provide various functions which are built into a single large interwoven unit. Teams really have to put in additional work to decompose these experiences into a manageable set of components rather than building a monolithic structure.
Fragility
There are a lot of ways a CMS implementation can be described as fragile – security, stability, performance, compliance. However, when talking about the marketing team, fragility takes on a new meaning. For content management teams, fragile is when you assemble or author a page and something breaks in the experience.
Examples of how can something break? Well, let’s make a quick list:
- When I add component X and component Y on the same page, I get errors.
- When I change the button to a clickable image, do analytics still work?
- If I edited page content, how do I know if I created a compliance issue?
Never-ending Dependencies
Back to the purpose of a CMS – make the marketer autonomous. If changing the page layout, or AB testing a header against a carousel is beyond the content management team, they have no choice but to ask for help from the development team. Development teams don’t typically sit around waiting for these types of tasks, so they get prioritized into the backlog and, well, these usually aren’t the most important tasks on their list.
Designing a Proper CMS Architecture
So, if the goal is to allow marketers to operate more efficiently and autonomously, what do we do in order to remove these obstacles?
Component Modularity = Flexibility of Design
If we only care about the initial state of a website at launch, we’re missing the point. In the design and development of components to be built, we have to go ahead and design in modularity so that the marketing team can combine components into patterns that were unforeseen in the initial production. Using accelerator frameworks like SCORE(TM) and Sitecore’s SXA help in this endeavor, but it’s up to the development teams to make sure that the CSS is done in a modular way as well to handle growth and adaptation.
Atomic Technology
The technology stack has to be modular too. There are some basic things that are a must – avoiding style by ID, etc. But one of the most common problems we see here is that the Javascript connected to a component or design pattern is created in a fragile way, or is not scoped properly and “leaks” from it’s boundaries into other areas of the DOM. In SCORE, we have an approach to handling this within CCF. View or controller renderings can connect JS dependencies – and the JS modules are aware of the wrapping DOM elements of the component and will limit its behavior to the “scope” of the view.
In RecentlyViewedProducts.cshtml
using (Html.BeginUXModule("Components/RecentlyViewedProducts",
new {QuickActionAvailable = Model.RenderingParameters.QuickActionAvailable},
new {@class = "recently-viewed bj-recently-viewed-products " + Model.Classes}))
{
...
}
In RecentlyViewedProducts.js
define(["jquery", "slick"], function ($) {
return function initRecentlyViewed(args) {
var $scope = $(args.scope);
var width = $scope.width();
var docWidth = $(document).width();
var tileWidth = docWidth - width;
var percent = Math.round(100 * width / docWidth);
var visibleSlides = (percent <= 46 && tileWidth >= 400) || (percent > 82 && tileWidth < 400) ? 2 : 4;
$('.slides', $scope).slick({
slidesToShow: visibleSlides,
slidesToScroll: visibleSlides,
dots: false,
infinite: false
});
};
});
Analytics
Basically, there are two types of analytics marketers care about – page view tracking and event tracking. Page view tracking is easy – the page URL is recorded along with the user session in the analytics data stream. Event tracking records user interactions with content that can be tracked independently from a web page or a screen load. Page tracking gives us some high level quantitative data about the usage of our website, but goal tracking and deeper analytics in our data layer comes from event tracking.
Making analytics manageable is possible, and in some cases you can bake-in analytics into purposeful built components. However, reusable generic components like buttons will suffer. This is a step development teams can take – provide rendering parameters or datasource item selections that allow you to select which events are triggered as a CMS author.
For Now….
To all of my marketing and design team friends – we’re trying to make your life better 🙂
