In the last few years, the pendulum of owning content-management software has swung from marketers to developers, led by the demand to move quickly and deliver content beyond the web, to multiple channels. The most popular CMSes of late, therefore, are those that cater to developers, but what are developers looking for and how do they prioritize the many systems out there?
A major challenge for developers is getting started. With systems that feature a quick start, developers can test and deliver fast, giving rise to happier bosses and teams.
Here are the three main areas where developers look for efficiency gains in onboarding:
Software as a service. With SaaS, developers don’t need to download as much software before starting development. Yes, they do need to download SDKs and set up the development environment and processes, but downloading and installing hundreds of megabytes of software and configuring databases are a thing of the past—unless you prefer the open-source route.
Quality documentation and examples. The fact that a product is only as good as its documentation holds especially true for systems with unique approaches to certain core concepts. The ability to learn through videos, documentation, example code, and content is critical for developers to come up to speed and start applying their use cases.
Trial accounts. Being able to sign up for and retain a trial account in a timely fashion means less time waiting and more time building. Also, how promptly a vendor responds to trial-account requests is a good proxy for customer service.
At its core, a CMS is a repository for content and the capability to query and deliver that content. Developers often emphasize the quality of a delivery API, which relates to these criteria:
Speed and reliability. Does the vendor offer a content delivery network (CDN) with a short response time? If so, is the CDN reliable?
Granularity of queries. Can developers easily assess the content they need and pull in referenced content without too big a payload?
Search. Can developers easily query and return content based on filtering and sorting criteria?
In other words, if they must make many calls or filter and discard output after the fact, developers are miserable, leading to lower performance. Similarly, the API format must make sense to developer workflows, e.g., are the calls for reading, creating, and updating similar?
Also, since many applications comprise a hodge-podge of underlying systems, you can detect development teams and patterns at work, which is why developers look for consistency in philosophy and API patterns throughout the development process.
While most modern headless systems use REST APIs, GraphQL is a query format that can make content-delivery requests more granular and easy to link. Not all GraphQL implementations are the same, however.
Similarly, your implementation might not need GraphQL.The importance of this criterion varies wildly, and your developers must lead the charge in ensuring that GraphQL fits your needs.
SDKs typically consist of “helper” and example code for various programming languages and frameworks. Developers are always interested in how well the example code is leveraged and updated.
More SDKs might not be better. Some CMSes focus on a single programming framework and, by continually honing the examples, build a loyal developer following.
As with APIs, developers are looking to see that the SDKs are consistent, well documented, intuitive, and complete, i.e., replete with functions for all use cases, not just baseline reading and writing.
Webhooks are triggers on tasks that help integrate your CMS into a larger composable architecture. Most systems have webhooks for content creation, e.g., triggering a preview or search-indexing task during content updates. Developers will often look to see if there are webhooks around system activities so that they can automate a higher level of administration and governance, if required.
In addition, developers would want to determine how much they can customize requests, such as with headers to pass on payload information. The more control developers have here, the more well-coupled the elements in your composable stack can become.
All headless CMSes offer content-delivery APIs—that’s the point of being headless—but not necessarily content-management APIs for content creation and editing tasks.
Besides, developers can manage the system itself through content-management APIs, which is important for automating and integrating larger tasks, such as updates to the content model, management of user roles and permissions, and import or export of bulk content.
A major challenge with headless content management is that the platforms are very developer-centric, and marketers who work with complex content often get lost through different dialogs while navigating multiple systems, content items, or assets. As a result, marketers must turn to developers for assistance.
Even though developers can mitigate that problem by customizing the authoring environment to meet the use case, the ability to do that is limited to what the vendor exposes. Developers will look for three levels of customization:
Field level: How easy is it to add field types and customize the UI for manipulating them, say, for a location or color picker?
Item level: How easy is it to tailor the editing process? Can developers make major changes to how the software looks and behaves during a content edit?
Application level: Can developers build larger dashboards? How about changing core behaviors, e.g., customize the application to show the three latest edited items or those edited by colleagues in the same team?
Developers might also want answers to these questions:
Command-line functions usually come as part of SDKs, ready for use by developers to automate portions of regular tasks. Here are two common command-line features:
Developers who are integrating CMSes into other products usually need advanced capabilities for building snapshots of content or configuration changes, including the ability to roll back or audit changes as part of a typical software-development life cycle process.
In conclusion, the more complex the requirements, the more developers will rely on the functions described above to build and integrate your CMS into your composable architecture. Hence, be sure to balance the needs of your content creators and marketers with those of your developers to ensure that the software can serve all their requirements.
Decoupled and composable architectures are gaining popularity because they address challenges posed by monolithic CMSes and other competing systems. As much as brands tend to focus on their CMS, Uniform's digital experience composition platform (DXCP)
demonstrates that experience management should be separate from content management.
Uniform DXCP is a composition tool that builds websites and digital experiences with data from CMS, DAM, and PIM systems so that your CMS can focus on provisioning content. Among the benefits Uniform offers, which many CMS vendors don't, are integrations with adjacent technologies for managing commerce and digital assets, efficacious CDN capabilities, and a preview feature with personalization context. Consequently, you can test multiple CMSes simultaneously to determine which one best fits your needs. Request a free demo