The Developer's Role in Elevating Marketing with XM Cloud

Introduction

The marketing team is in love with all the new XM Cloud features, and they are getting ready to sign the dotted line to start using it. You’re excited to jump in, but as a developer, you’re unsure how this will impact your day to day. Will the experience you have in the Sitecore platform transfer to XM Cloud? How can you ensure you’re supporting all these new features?

Understanding XM Cloud

Before we jump into how things are changing, let’s talk about WHY they are changing. For our purposes, we’ll focus on the “why” surrounding marketers and content authors.

Give the content team more freedom and agility

Before XM Cloud and without SXA, if the marketing or content team wanted to make changes across multiple pages using the same template, gain more detailed control over component layouts, or create a simple new component for a landing page, a developer's assistance would be required. Let's delve into these scenarios.

For the template-wide change, the author could theoretically modify the standard values of a template, but those would be lost on the next deployment due to the best practice of serializing developer-owned items like templates. Even if you just wanted to slightly modify the layout, alignment, or padding of an existing component on a single page, you’d better hope the developer thought about that ahead of time! In most cases, that granular level of control was not built in to most components, so you’d have to ask the developer to add that customization. XM Cloud solves both problems with Headless SXA.

Similarly, if you wanted a brand new component, even a simple one, it was impossible to create one without some coding taking place. If you had a campaign or landing page where you needed this new component on, you were faced with the challenge of going to the developer and hoping they could develop, test, and release this new component in time for your campaign. XM Cloud solves this problem with XM Cloud Components and XM Cloud Forms.

Reduce Overhead

Anyone who has used Experience Editor in the past can tell you that it’s not the fastest tool out there. In addition, as your solution and website grew in size and complexity, it compounded the issue. While Experience Editor played a crucial role in ease of content management, it was clear that performance needed to be optimized to help increase the throughput of marketing and content teams. XM Cloud solves this problem with XM Cloud Pages.

The Developer’s Role

With all these new tools that provide solutions to common problems, a natural question arises from developers. “How does my role change and how do I support the content team?”

To answer that, let's break it down by tool/feature.

1. Headless SXA (Renderings, Presentation Details, and Multi-Site)
2. XM Cloud Components
3. XM Cloud Forms
4. XM Cloud Pages

Headless SXA

While XM Cloud has brought tweaks for Sitecore Experience Accelerator (SXA), along with headless SXA support, SXA itself is not a new concept. SXA is an additional layer on top of the Sitecore. It provides functionality to manage multiple sites, their settings, and it adds tooling and building blocks to create websites easily. This results in authoring improvements for faster time to market and possibility for content editing to begin early. Below is an example of how a project workflow may look with XM Cloud, leveraging SXA.

With that overview out of the way, let’s jump into what this means for developers.

Renderings

Let’s begin with the most basic building block, Renderings. Before XM Cloud, we only had to worry about a few things:

Templates
Renderings (and associated items like placeholder settings)
Helix

But now that we’re on XM Cloud, we need to address a few additional items.

Helix is out, modules are in! Ok, it is not that drastic, but you will notice a large shift from helix-based organization to a flatter structure underneath a project in XM Cloud. Does this mean we lose all the Helix goodies? Not quite. With SXA Modules, we get back the main benefits of Helix, which was managing dependencies and packing items and files together.

SXA Modules

“An SXA module consists of templates, branches, settings (to store scaffolding items), media library items, renderings, layouts, and so on.” Source: Sitecore Documentation

Sounds like a helix feature, doesn’t it? That’s because for all intents and purposes, it is a helix feature. So, what’s different about them?

It’s mainly how they are created and used on your sites.

First, you’ll no longer want to create renderings, templates, etc. from scratch. Instead, you will be using XM Cloud scripts to do the scaffolding for you.

Here are some references to get you started:

Once you have a module created, you’ll be cloning existing renderings into your modules. This will automatically create most of the scaffold required for your new components. This includes templates, renderings, placeholder settings, rendering parameters, insert options, etc. Here are some references to get you started:

While the process of creating renderings and SXA modules continues to be developer-focused, it creates the foundational building blocks required for the rest of the Headless SXA features to enable the marketing and content teams.

Presentation Details

With our foundational building blocks out of the way, we need to place our renderings onto a page. Here is the first major shift in how we do things to ensure marketing and content teams can make changes without requiring a developer in the future. Traditionally, we would create page templates and inside of _Standard Values we would place the default presentation details. With XM Cloud, no more!

Page and Partial Designs

First, you would still create your page templates as we typically would, but with XM Cloud, you wouldn’t place any presentation details on your page’s template standard values. Instead, we’ll use SXA to assign page designs to those pages. Below is a great illustration by Sitecore that provides a high level view of how this will work.

As you can see above, we now place our renderings inside of “Partial Designs” and then we can assign one or more partial designs to a “Page Design”. Once we have that, we can use the Page Design root item to map different page templates to the page design we want them to use.

Reference: https://doc.sitecore.com/xmc/en/developers/xm-cloud/create-and-assign-a-page-design-in-the-content-editor.html#assign-a-page-design-to-a-template

The beauty of this setup is that it allows authors to create and update partial designs and page designs without the explicit need of a developer! Of course, developers will typically do most of the initial setup, but once that is there, the marketing and content teams can make it their own with little overhead.

While you’re building your designs, make sure you’re extensively using the grid system provided by headless SXA built into XM Cloud. Here are some references to get you started:

Using the grid will ensure that if the authors want to make layout changes in the future, they can simply modify the properties of the grid without requiring more development.

Multi-Site

If you’ve gotten this far, that means that you now have modules and page designs for your website. You may have even started using them on your website. Soon, you’ll want to use all the hard work we’ve done on another website for the same organization. But we’ve been placing everything under a project, how will we share it with another site? Here’s where SXA really starts to shine.

In Headless SXA, you can configure a website as a “shared” site. This will allow other sites to use rendering variants, styles, partial designs, and page designs from the shared site.

Let’s show an example. Below is a structure of one of our XCentium accelerators. Notice we have a total of 4 sites.

In our example, “Starter Kit” is our tenant, and “Default” is the site we want to share with all the other sites. To do that, we select the tenant and add the Default site to the “shared sites” fields.

The next step is optional, but if you want to share all the available renderings with the other sites, you’ll want to do this step. Go into your shared site, “Default” in our example, and enable sharing on our Available renderings.

Sharing doesn’t stop at this point; you can also share content with other sites by using Headless SXA’s delegated area feature. Here is a reference to get you started: https://doc.sitecore.com/xmc/en/developers/xm-cloud/share-content-as-a-delegated-area.html

This sharing not only allows developers to quickly reuse work across multiple sites, but it enables the content and marketing teams to quickly create micro-sites with minimal effort.

XM Cloud Components

XM Cloud components give an additional level of control to marketers that cannot be achieved with SXA-based components.

“XM Cloud Components is a Front End as a Service application that let's you create your brand’s style guide and build visual components in a WYSIWYG editor.” Source: Sitecore Documentation

They sound awesome, so why are they so far down the list?

XM Cloud Components represent a leap forward in Sitecore's technology and innovation. While they offer many use cases, they come with limitations to consider.

When are XM Cloud Components great to use?

Static or semi-static data
No connection to other components (if x happens on one component, then y should happen on the other)
Quick turnaround for a campaign where developer time is limited
Some performance overhead is acceptable

When are XM Cloud Components not great to use?

Needs connection with other components / state management
Complex UI with many variations
Performance is of upmost importance

As you can see, while they have their limitations, they can be a great option for many use cases. How, as developers, can we ensure we’re properly supporting XM Cloud Components?

It’s a lot simpler than you may initially think. Because XM Cloud Components are completely dynamic, we just need to make sure we support the injection of these dynamic components. Luckily for us, the XM Cloud Next.js Starter Kit includes just that. That means that out of the box, we fully support XM Cloud Components!

For the curious, the file we’re looking for can be found here: https://github.com/Sitecore/jss/blob/dev/packages/create-sitecore-jss/src/templates/nextjs-xmcloud/src/components/FEAASScripts.tsx

Once you confirm you have that file in your solution already, all we must do is configure the styles in XM Cloud so that marketers and content teams can use them. Below are some great resources to get started.

With that configuration completed, the marketing and content teams can now create components on the fly with no development required.

Overall, when you need a simple, static or semi-static component, XM Cloud Components are a great route. The major pitfall to be mindful of is the fact that the moment at least one XM Cloud Component is used on a page, it will trigger some additional network requests to pull things like stylesheets for the XM Cloud components. This stylesheet typically scales with the stylesheet itself, not with how many components you have on a page. As a result, careful consideration of how large the stylesheet grows must be taken.

XM Cloud Forms

With a WYSIWYG editor, XM Cloud Forms let's the team create forms without any development. There are some dependencies it requires, but once those are met, it’s a simple drag and drop.

Does this mean we should create every form with XM Cloud Forms?

The short answer is no. Like every other tool at our disposal, we should carefully consider in what scenarios the tool is best used for. Here are my thoughts on when you should and shouldn’t use XM Cloud Forms.

When are XM Cloud Forms great to use?

Marketing Forms / Lead Generation
Unique forms for campaign landing pages
Minimal/no dependencies on other services

When are XM Cloud Forms not great to use?

Highly Integrated forms, like authentication forms
When many dependencies/services are required for the form to operate properly
Pre-populating fields required

This means that depending on your project needs, your marketing team may be able to have complete control of almost all the forms on the website. In other cases, you may find that developers will be the owners of forms and modifications.

Forms are another item that is automatically supported with the Next.js Starter Kit, and it uses the same component wrapper we spoke about for XM Cloud Components. Similarly, we’ll only need to configure the styles for the forms so the teams can select from them.

With that configuration completed, the marketing and content teams can now create forms on the fly with no development required.

If you want to learn more, check out the great documentation by Sitecore at https://doc.sitecore.com/xmc/en/users/xm-cloud/forms.html.

XM Cloud Pages

XM Cloud Pages is the latest editor for XM Cloud. It provides a WYSIWYG editor to build and modify pages. The origin from XM Cloud Pages seems to originate from Horizon, with many polishes along the way.

Luckily for developers, things don’t change much. If your code base was Experience Editor friendly, it will work perfectly with Sitecore’s new Pages editor.

The main difference will be how you test things locally. Since Pages is a cloud-based solution, there is no way to spin up a Sitecore Pages instance locally. Instead, you must follow the short steps found on the following documentation to get it setup: https://doc.sitecore.com/xmc/en/developers/xm-cloud/connect-xm-cloud-pages-to-your-local-xm-instance.html

Getting Pages setup locally is crucial in the development workflow because it allows you to ensure your content and marketing teams are getting a good experience with everything you build.

Conclusion

In conclusion, the transition to XM Cloud marks a significant evolution in how developers support marketing and content teams. By leveraging the new features like Headless SXA, XM Cloud Components, and XM Cloud Forms, developers can provide a more agile and responsive environment that empowers non-technical users to take greater control over content management.

While this shift does introduce new tools and processes, it also simplifies and enhances the overall development workflow, enabling faster time-to-market and reducing dependency on developer intervention for routine tasks. Embracing these changes not only elevates your role as a developer but also strengthens collaboration with the marketing team, ultimately driving more efficient and effective digital experiences.