Sitecore Experience Accelerator – What It Is And Why It Matters

A lot has been made recently of the new Sitecore Experience Accelerator (SXA, or sometimes just XA).  Sitecore has released some details around it (you can find an overview here and more details here), and with the release of 8.2 at the end of last month, more and more people are starting to get their hands on it, use it, and make their own determinations.  I offered a quick overview of SXA, along with Helix and Habitat, in this blog post last week.  In today’s post, George Chang (@sitecoregeorge) and I (@stephentynes) would like to dive a little deeper into SXA specifically and share some of our thoughts and learnings.  We’ll start with a quick excerpt from the previous post:

“SXA is a set of toolings and processes to allow the rapid creation of websites by increasing the amount of work that can be done in parallel.  Historically, visual design was started and development didn’t start until those activities were nearing completion.  SXA uses Sitecore’s separation of presentation and content that allows the creation of data templates, an information architecture, and essentially the building of a skeleton website to be done while visual design is still in process.  Once the visual design is completed, it can then be used to complete the visual renderings. Additionally, the SXA process supports the proper structuring of content so that personalization and other features can be easily applied to the completed website.”

Revolutionize Your Business With Generative AI

From product design and software development to virtual agents, content creation, and reporting, GenAI is transforming business. Our AI experts help you unlock GenAI’s full potential and drive growth.

Let’s Get Started

So with that as the backdrop, let’s dive in.  Here are some of our key thoughts:

1. Adoption. One of the goals of SXA is to create a set of best practices that can be used and reused across many different websites. This accelerates development and minimizes risk for the implementation of a single website, but it also allows developers to more quickly and efficiently transition from one implementation to another because there are more similarities between the two. It’s easier as a developer to get your bearings and understand the patterns used because you’re already familiar with them. But this second goal is only realized if the adoption rate of SXA is high. If it’s not widely used, then you don’t gain the critical mass necessary for it to truly become the standard or preferred way of implementing a Sitecore website.
2. Licensing. This can have a big impact on adoption, and we don’t yet have a lot of details around the way that SXA will be licensed.  This page provides a link to “How you buy,” but the resulting page here doesn’t offer any details of the pricing.  The indication on the first page is that it will be based on “environment size.”  This could be based on the number of servers or as a percentage of the overall Sitecore license cost.  In any event, it may be a stretch, especially for customers that have already made an investment in Sitecore, to go back to the well, so to speak, to come up with additional money for licensing. More to that point…
3. New or used? I think it’s easy to see the benefits that SXA brings to a new implementation.  But what about the existing customer base?  Will current customers, even as part of a brand refresh or an upgrade to the latest version of Sitecore, find the benefits of SXA such that they’re willing to reinvest in additional licensing fees?  For the sake of overall adoption, I hope they do, but I admit that I’m a little skeptical on this point.
4. Tooling. This was mentioned previously, but we didn’t really put a lot of meat around it.  So what do we mean by this?  SXA comes with a number of predefined “components” that consist of 2 parts.  The first part is the data model.  All of the components have a defined data model, as well as a default UI rendering.  So for example, if I add an SXA Image to my page, I need to input the corresponding data, like the reference to the image to be displayed and the URL that the image should navigate to (if applicable).  SXA also includes inputs for a placeholder that the component is assigned to, various styling properties, and the standard Sitecore administrative properties that we’ve become accustomed to, such as workflow, last update, etc.  So far, all of this is fairly typical to our normal Sitecore experience.
5. More tooling. The second aspect of the tooling that SXA provides is where we start to see some of the real benefits of the accelerator.  For each SXA component, a default cshtml rendering is also provided (yay for native MVC support!).  To start, the rendering is just a giant X on the page that SXA calls a “wireframe.”  [ASIDE: I’m personally hesitant to use that term because I fear it can be confused with wireframes that are created by experience designers working on the project.  In my experience, even an initial sketch (which usually precedes the wireframe, which precedes the visual comp: sketch -> wireframe -> visual comp) is typically produced at a higher level of fidelity than these SXA wireframes.  We don’t want to confuse the SXA process with the visual design process.] Once added, this rendering is then visible on the page and serves as a starting point for creating the final design.  It serves as a placeholder for you to go back in and apply a theme with the final HTML / CSS / etc. in order to finalize the look user experience of the website.  The existing HTML and CSS can be exported as part of a theme package, and front-end developers can update the package with their final style updates.  The final theme package can then be uploaded back into SXA and applied to the entirety of the site, thereby changing the basic lines and placeholders to a full-fidelity web site.
6. For demos or production? These toolings, both the data templates and the renderings, can help speed the development of the website if they align to the types of components that you need for your website.  There’s a variety of these components included in SXA such as images, carousels, calendars, etc.  If these types of controls don’t align to what you need to create and you’re going to end up customizing them heavily or having to create your own data templates and renderings, you may not see the same level of value from SXA that others do.  That will determine whether or not SXA is just something you want to use for demos and rapid prototyping or if it’s something you feel comfortable building a production-ready site on.
7. Process. Like the tooling, we mentioned the process earlier, and this is one of the areas where I feel like SXA shines.  Often times customers and designers don’t have the same level of experience working with Sitecore that we as architects and developers have.  SXA can help force alignment between these groups earlier in the process.  Notice that I said “can help.”  I don’t believe SXA is required to do this, but I do think it can contribute to it.  SXA helps drive alignment on: what is / is not a component; where components can be reused vs. requiring a separate component; what exact data model is required; etc.  All of these things are incredibly beneficial to the overall project and delivery.
8. Content entry. Another big benefit that the process of SXA provides is the ability to start entering content earlier in the process.  Since the data templates are created and the components are added to the skeleton pages, the business users can go ahead and start entering content.  The rendering is going to be sorely lacking so there will have to be adjustments made later depending on font size, wrapping, and similar considerations, but it may minimize the need for tools such as GatherContent.com or the trusty ol’ Word and Excel documents that we spend so much time copying and pasting from.

These are some of our key learnings, but we’d love to hear more about your experience. Feel free to comment below or follow us on Twitter at @stephentynes and @sitecoregeorge!