When building out a customer experience management (CXM) software architecture, organizations have to choose solutions from more than one vendor and stitch them together into a platform. In terms of digital experience (DX) delivery, this means different applications that facilitate the customer experience at different touchpoints must be able to share content and data so that the brand’s look and feel, its voice, and its message remain consistent throughout the customer journey.
When we think about what content needs to be shared and accessible to marketing, commerce and service practitioners, we usually think of discrete, stand-alone assets like logos, photos, videos, infographics, or maybe even chunks of boilerplate copy. But in the age of omni-channel, digital-first communications, we really need to be able to go beyond sharing just the content in a communication.
Now, to be consistent and efficient across channels and across the tools in a digital experience platform, we need to be able to share the building blocks of communications -- style sheets, layouts and templates -- the ways in which copy and assets are arranged and presented, customized for each channel through which communications can be delivered.
The Assets We Don’t (Yet) Share Well
At this stage, it’s important to distinguish between style sheets, layouts and templates.
- Style sheets allow users to apply the same stylistic decisions -- such as the font face, size, weight, and color of a main headline (i.e., H1) versus a subhead (e.g., H2) -- across communications.
- Layouts may make use of style sheets to create a consistent look and feel, but they have more to do with where content objects appear on a page or screen in relation to one another.
- Templates determine which content objects will be used (based on business logic and available data) and provide the context for each communication.
If you and your DX applications maintain this separation among style sheets, layouts and templates, then it’s possible to share all three.
Sharing Style Sheets
Style sheets have the longest history of being shared, or at least attempted sharing, among applications compared to layouts and templates. The most popular ways of defining style sheets for sharing are CSS and XSL. Some software suites, such as Adobe Creative Suite and Microsoft Office Suite, have their own versions of style sheets that they’re able to share amongst themselves. For example, you can share stylesheets across Word documents. Adobe took it a step further and allows the user to create shared stylesheets called libraries. But sharing style sheets across applications from different vendors remains a bit more challenging.
While a shared style sheet allows for some consistency of look and feel -- headers will be the same font, size, color and boldness everywhere the stylesheet is applied, for instance -- a stylesheet limited to text doesn’t help with layout, or where different content objects appear in a document, on a web page, in social media, etc. We need to be able to share layouts and templates across applications, too, which so far isn’t really being done.
Sharing Layouts and Templates
Topdown does distinguish between style sheets, layouts and templates, so we are able to entertain the idea of sharing them with other applications. However, at the moment, sharing appears to mean different things to different vendors.
To be able to use the same assets -- both content elements like images and text and assets like stylesheets, layouts, and templates -- across multiple applications, we need to use some common standards. Using the same format (e.g., CSS and HTML) across applications is good. However, while many DX applications may define styles in CSS, for example, today you need to manually create and name style sheets for users to access within each application. That requires some heavy lifting to maintain; if anything about any style sheet changes, the enterprise architect would have to manually update the stylesheet in every system.
The ability to import and export stylesheets, layouts and templates would be better, especially for business users. The best situation, though, would be incorporating a workflow or management layer that can help coordinate versioning between applications.
Borrowing from the Web World
The philosophy that we’ve adopted is that content should always be considered universal. It should be usable in any communication going out to any channel. Content should be separate from layouts and templates (they should simply refer to content). The formatting of that content -- where it appears in a communication and how it appears -- should be “late binding,” meaning it should be decided at run-time as communications are being created. So you may have the same chunk of text that looks different by channel (web, print, mobile); the font could be different, where it appears in the communication could vary, etc., all decided based on the specific channel’s requirements. If you do that, you’re separating layout and content.
In the past, customer communications management (CCM) has been strongly print-driven. We’ve all been designing for print first and converting those documents to digital later. Now we have to be digital-first and borrow from the web world.
In web design, we’ve been using layouts underneath web page templates for years to define where some piece of content goes relative to other pieces. Moreover, to be fully responsive, we can’t really consider positioning of content to be absolute. Instead, the layout establishes regions or “containers,” like header, body, footer, and determines where each region goes on a particular screen size or piece of paper. In the template, you might further define containers to hold, for example a logo, some boilerplate copy, an address, a footer, and some business logic to drive what else goes into the body. The content management system using the template resolves any variables and business logic in the template to product the final-format communication (e.g, a web page).
How to Get There from Here
Most companies have arrived at some sense of similarity across communication types. For example, all their letters will look alike; all their newsletters will have the same look and feel; all their invoices will look and function the same, etc. Each type of communication will have its corresponding layout. But there will still be differences across departments or lines of business, such as claims department correspondence being different from service or marketing communications. Essentially, when you consider what exactly goes into each department’s content, you’re talking about layouts and templates. When you then personalize a template for a particular customer, that’s when you move from template to actual final-form communication. So, metaphorically, we’re moving from raw construction materials to a floor plan to walls and a ceiling to what furniture and artwork go in each room.
But how do we get from where we are now -- which is largely unable to share assets like layouts and templates -- to where we need to be, which is seamless shareability of both content objects and full assets?
It can be done in a variety of ways, including using APIs or workflows. But what we’re watching most closely is CMIS4DAM, which is a technology currently in development that is specifically designed to facilitate content management interoperability for digital asset management. The OASIS CMIS4DAM Technical Committee is currently working hard on defining this extension of CMIS, and their intention is to eliminate the need for expensive custom integration by enabling standard protocols for digital assets to travel more freely and efficiently between different systems.
All this is an acknowledgment that digital asset management needs something more robust to serve all the different software systems, people and processes within an enterprise organization – including customer communications management. We’re looking forward to the day when we and our customers don’t have to work quite so hard to achieve interoperability. And we hope that CMIS4DAM will at least partially solve the problem of sharing stylesheets, layouts and templates.
Why Being Able to Share Assets Matters
Being able to share stylesheets, layouts, and templates as well as reusable content objects across applications and platforms is important because of brand consistency. Presenting a consistent brand leads to a consistent customer experience (CX). Consistent CX leads to a feeling of familiarity, which promotes trust, as well as ease and effectiveness of use, which in turn generates positive emotion. That builds loyalty, which leads to repeat business and increased revenues.
If you’re interested in topics like these and would like to share ideas with likeminded professionals, then we encourage you to check out and request to join the Customer Experience Architects group on LinkedIn. I hope to see you there!
