Composable Challenges: Strategies for Dealing with Missing Features

Introduction

Systems that provide individual Packaged Business Capabilities (PBCs) used in composable solutions may not include certain features that the organization desires. Specifically, headless Content Management Systems (CMS) used for composable digital experience management solutions do not inherently allow non-technical content contributors the intended level of control over web page design, requiring handoffs to design and development teams to achieve common goals such as new landing pages. These limitations frustrate CMS users and reduce agility and increase the time it takes to deploy design changes and new designs. Software tools such as Kajoo have emerged to address these challenges.

This blog post is part of a series about challenges that organizations face when implementing composable solutions. For more context on these topics, please read the introductory post before proceeding with this one.

Before the emergence of composable architecture, Content Management Systems (CMS) that included HTML generation engines could allow non-technical users some capabilities for controlling page design. CMS users were typically able to select which presentation components appeared in various locations on each page and to control styling and other aspects of those components.

Headless content management systems used in composable architecture do not include features to generate HTML. Some headless CMS vendors provide facilities to generate web pages, but using these options re-introduces increases coupling between the content delivery front-end and the content management back-end, which headless CMS and composable architecture intend to reduce. Using a CMS vendor’s presentation technology also limits architectural options, such as preventing the front-end from retrieving content directly from a search index or Digital Experience Composition (DXC) product rather than directly from the CMS itself.

Organizations can implement custom solutions that let users control page design. Developers can add dropdowns and other features in the CMS to let users choose predefined presentation options. This approach requires foresight and custom development, and tend to be restrictive, cumbersome, or both.

Many organizations want to empower business users with greater design capabilities than those provided by any CMS, whether headless or not. Rather than using existing page designs, selecting which presentation components appear on a page and in what order or locations, and configuring those components, many CMS customers want to grant business users the ability to implement completely new presentation components or even entire pages without relying on designers, developers, or cumbersome release management processes.

Design Control

Business users want the ability to control not just the data that they enter into the CMS, but the appearance of that data on the website. Almost any solution must grant CMS users some control over layout and styling without involving developers in every minor change. As a generic data management technology, headless CMS does not inherently grant business users control over layout (page structure), presentation (which components to use), and styling (color, spacing, and otherwise).

The “rich text” field type that has been available in almost every offering since the release of the first CMS demonstrates that the need for content contributors to control presentation has always existed. This field type allows business users with no knowledge of HTML to style their content, providing What-You-See-Is-What-You-Get (WYSIWYG) editorial capabilities.

While it is possible to use rich text fields to implement entire web pages, this approach presents challenges and limitations, and most professionals in the industry consider it to be very bad practice for several reasons. Rich text fields do not separate content from presentation, do not support componentization, and typically grant users too much or too little control, resulting in inconsistency or excessive restrictions. The functionality provided by the rich text field type is important, but it applies to individual fields that can appear on a page, where CMS users often require WYSIWYG control over entire pages rather than individual fields.

The visual aspects of web pages that CMS users need to control include which presentation components appear on the page, the locations of those components and in which order they appear, various aspect of styling for each component, and from what CMS records each component retrieves its data. Some headless CMS products can provide relevant capabilities, but only if the implementation team uses specific technologies from the vendor to build the solution. This tightly couples the custom front-end to the CMS back-end, which defeats some of the main objectives of headless CMS, locking the customer into the vendor’s solution. Business users need to be able to control designs without requiring the solution to use a specific vendor’s technology.

Rather than using the vendor’s front-end implementation technology, organizations can implement custom solutions in the CMS to allow users to control presentation, such as drop-downs in content records that let users select from predefined lists of presentation components and styling variations. Unfortunately, each design aspect that users must control requires custom development as well as its own selector in the content entry user interface, which quickly results in an overwhelming data entry form for content contributors.

Organizations need the ability to let non-technical business users control their page designs based on existing components without relying on designers or developers or being forced to use specific technologies dictated by the CMS vendor.

New Designs

In addition to the ability to control visual design aspects of pages built from existing components, many organizations want their business users to be able to implement new presentation components and entire page layouts without depending on other teams. The process for implementing new page designs typically requires business users to detail their objectives for designers, who then hand their work off to developers for CMS implementation and deployment. Handoffs of ideas and artifacts between marketing and implementation teams increase costs and create friction in the creative process, which increases time-to-web, reducing agility.

Optimally, non-technical business users could create new presentation components and design entire pages without depending on designers and developers. Design-to-code, Front End as a Service (FEaaS), and low-code/no-code solutions have emerged to address aspects of this need, but the result is typically a solution that feels standardized and templated, offering little differentiation from the organization’s competitors. Additionally, the components generated by these tools often require modification to retrieve data from a specific CMS, commerce, or other solution. This requires developers, which largely defeats the objective of empowering business users to make design changes independently.

Recently, the role of “citizen developer” has emerged in some organizations. Citizen developers provide a sort of bridge between non-technical content contributors and design and development teams. Citizen developers are not trained designers or developers, but have some understanding of HTML, CSS, and the CMS, and therefore can implement code required for the business team to pursue some of its initiatives. Few organizations have committed to this approach, which is promising, but the potential of which has yet to be determined.

Solution: Kajoo

Kajoo (https://kajoo.ai/) is a no-code platform that enables designers, citizen developers, and content contributors to implement and update design components for CMS-driven websites. Kajoo automatically converts their work to code that can access the CMS and deploys that code to the content delivery tier.

With Kajoo, anyone can implement features for the website. Kajoo users can create new designs from scratch in a browser-based pallet that works like a WYSIWYG editor for entire page layouts and individual presentation components rather than styling text in individual fields of the CMS as they would in a rich text editor. For designers, Kajoo can import from Figma (an industry-leading design platform). For citizen developers, Kajoo can import fragments of HTML code. For CMS users, Kajoo can use Artificial Intelligence (AI) to transform hand-drawn sketches into page layouts and individual presentation components. In all cases, Kajoo converts the user’s work into CMS code ready for deployment to the content delivery tier and provides features to perform that deployment.

Through its use of artificial intelligence and automation, Kajoo eliminates expensive and time-consuming handoffs between CMS users, designers, and developers. Kajoo lets every member of each functional role focus on the tasks at which they are most productive and add the greatest value for the organization. Kajoo increases user capabilities and productivity while reducing frustration and time-to-web for new initiatives.