January 29, 2018 by Jacqueline Baxter

A Content Creator’s Guide to SXA

By now you’ve probably heard something about the Sitecore Experience Accelerator, commonly known as SXA. As the name would suggest, SXA is an accelerator meant to help teams build Sitecore websites more quickly. It was first introduced in Sitecore 8.2, and with the introduction of Sitecore 9, in the immortal words of Disney’s Hercules:

Disney Hercules Atropos it's gonna be big

SXA has a metric ton of features that are meant to smooth out some of the more common challenges that can come with Sitecore development. I’ve used SXA on a few builds now, there are several things about it that I like. Starting with:

Speed and Teamwork

SXA is Sitecore’s answer for increasing the speed of development (i.e. the development team doesn’t have to listen to me asking over and over again if I can start now). With SXA, back-end, front-end and content are working almost in parallel, and that can save time in a project cycle. But with great power comes great responsibility – SXA won’t stop content editors or creators from building weird and difficult layouts the way that Sitecore proper will, so it’s my job to work with back-end, front-end and UX to understand the intended structure and operation of the site as well as our imposed limitations. Teamwork makes the dream work, and all that.

Iteration

SXA brings in the content team earlier and lets us work directly with what will be the final product. That kind of early access has perks: not only can I start iterating earlier, but I often find bugs and missing features early on. I’m much more likely to discover that something doesn’t work the way I need it to when I’m actually importing content; SXA opens up a stage in the project somewhere between ‘development’ and ‘QA’ where I’m much less afraid to ask if something can be fixed, altered, or built to my specifications.

Re-usability and Variants

SXA provides many core renderings right out of the box, and your talented team of developers can no doubt build you more. This is where variants come in – as Una Verhoeven explains in her excellent blog post “We use variants to change the presentation of the data while keeping the same underlying data structure. This gives the content editor lots of flexibility when building a site.” This is great for me, because it allows me a measure of flexibility while ensuring that the core design and UX principles of the site are adhered to. There’s so much less screaming.

The experienced among you are probably thinking, “…but I had a component library and variants in Sitecore already” and you would be correct, to a certain extent. I asked Senior Solutions Developer Elena Mosoff to walk me through the differences, and she explained that when we talk about ‘variants’ in the context of Sitecore Experience Accelerator we’re talking about SXA presentation variants, which do not exist in Sitecore proper.

She broke it down this way: “With SXA variants a developer can essentially control the html markup that's going to get generated entirely within the Sitecore editor. With non-SXA Sitecore, any variants you see (such as Image Left vs Image Right), a developer has added that variant in code and done additional configuration. Using that example, let's say you have Image Left and Image Right, but you want to add a third version - Image Top. With SXA, a developer goes in and add the variant straight in Sitecore as an item, telling it what markup to render, no code required. With non SXA, a developer would have to add that variant in their code and do a deployment before the content team would see it as an option. Both ways do require styling from front-end, but from a back-end perspective the SXA way is much faster; the content team can see the new variant right away and is able to start to use it even before styling is complete."

As with Everything, There’s a Learning Curve

Disney Hercules 3 fates word of caution 

SXA doesn’t operate the way that Sitecore proper does, so things look and feel different, and many of the tricks and short-cuts you’ve taught yourself to speed things up won’t work with SXA. Accordingly, it requires a completely different skill set than Sitecore does. And it’s very important to note that SXA is still in active development – each version that’s released is better than the last, but things will still sometimes break down in ways you were not expecting. But if you need to stand a new site up quickly, or if you’re working with a team of people who aren’t that familiar with Sitecore (or have never worked with it before), SXA is a good place to start.

Keep in Touch and Stay Informed

Get updates, industry reports, white papers and more Hedgehog love.