Customizing and Extending SaaS Headless CMS User Interfaces

This blog post contains information about customizing and extending SaaS headless CMS, though some of this information may apply to any SaaS solution.

By customizing, I mean anything that a CMS user with appropriate access can achieve by setting values through a browser-based user interface or HTTPS service endpoint. By extending, I mean anything that involves code written by the customer or a third-party. Most CMS include field validation through regular expressions, which I consider a form of customization, where extension would involve validation with custom code.

SaaS headless CMS UI customization could involve at least the following:

• Defining content types, setting system properties to control text and other aspects of CMS visual appearance and functionality such as WYSIWYG editor configuration and data entry validation.
• Enabling and disabling CMS features, generally based on roles.
• Configuring publishing workflow.

SaaS headless CMS UI extension could involve at least the following:

• Custom field validation.
• Custom user interfaces at a dashboard level.
• Custom field types/field editors.
• Custom entry editors that augment or replace the default field editing interface.

Custom field validation is relatively straightforward: if the vendor supports it, use it when default CMS features do not meet requirements.

Custom dashboard elements typically render metrics such as analytics and allow triggering and monitoring of processes such as search engine index rebuilds.

Custom entry editors and field types can improve usability, especially for working with complex data structures and large data sets within a single entry or field value. Entry editors and field types are functionally similar in that can achieve almost anything, returning the result as JSON for storage in a CMS entry.

Entries contain fields that can contain zero or more iterations of zero or more values. Field editors manage a single field value, where that field value may be a JSON structure that consists of multiple sub-values. Entry editors manage all the field values in an entry, either replacing the default field editing interface or providing an alternative user interface for the entry.

A common use case for a custom field type involves a drop-down for which selection controls values in another drop-down, often using values from an external system and storing the values selected in each field as a JSON structure that contains both selections.

Both field editors and entry editors can perform custom validation, but entry editors can validate and otherwise manage values for multiple fields. Both field and entry editors can present a user interface that integrates with other applications, often storing references to values in those systems back to the CMS. Typical content types include some fields of the default field types with zero or more custom field types. Few content types use custom entry editors completely in place of the default field editing interface.

Custom field types also benefit solutions by storing complex data structures in a custom JSON formats rather than using a proprietary format defined by a vendor, increasing vendor independence.

See also: SHCDAS: SaaS Headless CMS Integrations and Extensions – Deliverystack.net

Please comment on this blog post to share any perspectives on customizing and extending SaaS headless CMS user interfaces.