February 13, 2018 by Hedgehog

SXA: A Hedgehog Live Chat

Jackie (Jacqueline Baxter, Marketing Specialist): Welcome to our Hedgehog live chat! For discussion and debate today, we're talking SXA, the Sitecore Experience Accelerator. SXA is a major topic of conversation in the community these days. Since most of us have worked with it I’m interested in overall impressions. What do you like about SXA?

Una (Una Verhoeven, Senior Solutions Developer): I like that developers can spend time on some other development, like integrating services, backend tooling, and CRMs instead of spending time on building the navigation and a page. SXA also forces you to use certain structure which is good, especially for content editors. It keeps things clean, especially big websites. Plus, there are big additions to the Experience Editor.

Charlie (Charles Turano, Senior Solutions Architect): For certain kinds of websites, SXA really helps out. The out of the box components will allow you to quickly produce a functioning website. The ability to somewhat separate the front-end tasks from the back-end tasks helps improve the flow of site development.

Andy (Andrew Karaptis, Senior Solutions Developer) : It focuses a project more on component-driven design and provides content editors with a robust "page builder" where they can mix and match components into full pages. Some content editors and marketers want this freedom to make their layouts and pages less static.

Mike (Mike Shaw, Client Success Manager): As an editor, I feel it gives me slightly more control and efficiency than the traditional editor. The biggest benefit I find is more aligned with mindset than usage though. Like Andy said, SXA requires us to change our mindset from traditional flat pages to true component focused page building. Which in my opinion is the right direction for us to go in.

Jackie: I'm seeing a lot of mention of content editors and how SXA helps them, which I agree with. I have found though that there's a learning curve with SXA that users might not be expecting; the interface isn't the same as it is with Sitecore proper. Can I call it that? I'm calling it that. Has anyone else had a similar experience?

Charlie: SXA adds a bunch of functions to the Sitecore Experience Editor, so in that regard I see it as an enhancement (other than performance). The nice part is that it will not require a content editor to unlearn most of the things they know.

Mike: Hmm, this is a tough one. I can see many of the same processes for updating and editing content that has been used in the past. I do feel I had to really re-learn a lot of how to build pages as it forced me to operate slightly differently. That may not be a negative - it forces everyone to think and approach pages differently.

Jackie: Yes, exactly. I'm not saying it's bad, just something to be aware of.

Andy: I agree with that. I think there's always a trade-off between content editor power and content editor ease of use. Most website owners like the sound of a robust "page builder", although they may not realize it takes more content editor work to use. In return for that extra effort, content editors have a lot more power than they would with more traditional content editor tools like static page templates that have static lists of content fields.

Charlie: The re-learn thing is more implementation specific. Each Sitecore implementation is somewhat custom, making the components for the page unique. The ability to add components, personalize, test and update is common across platforms, and doesn’t change with SXA.

Mike: Editors shouldn't fall into the “old dogs can't learn new tricks” routine either. SXA is different and as creatures of routine, the typical reaction to change is negative.

Andy: I think it’s like any tool - they all have learning curves. But can they benefit you in the long run once you learn them? SXA page builder probably can be useful to many business and marketing needs once you understand how to use its features. It is probably a no-brainer way to accomplish some types of marketing goals, like being able to quickly create landing pages with unique layouts from a list of predefined components that you can stack into grids.

Jackie: The variants are very helpful, as is being able to get in there earlier as a content team. Andy makes a good point - there are some cases where SXA might be the best choice for a project. What are some of those ideal use cases?

Una: I am still waiting for someone to convince me that SXA is not a good candidate for any project.

Andy: Being able to get content entry work started before front-end development is complete is an interesting benefit. You can run content entry effort and front-end development in parallel, which is typically not possible. That could be very helpful on projects with lots of content to enter and tight launch timelines.

Mike: I think much of it depends on the know-how of the editor. If you have an editor just learning Sitecore SXA will be a great tool to make truly flexible pages where they can see the results as they build. I can see that as being a bit cumbersome for large content projects where building through the good ol' content editor will still be much faster.

Jackie: I think that goes back to team experience with Sitecore too. A content editor with a lot of Sitecore experience might frequently find the content editor faster.

Una: For editing content yes. For creating a page, no. The combination of the two is a nice one to have, but that all depends of the content editor.

Mike: Can you expand on that,Una? I don't understand how creating a page would be easier on SXA. Maybe I don't understand what you mean by "creating" though; I'm thinking about large content sites where I need to make, let's say, 500+ blog pages.

Una: SXA lets content editors basically drag and drop when creating a page. Creating a page otherwise means teaching content editors to use Page Details, placing renderings and typing placeholder names. You need to be a techie for that. Editing a page in the content editor might be easier but building a page won’t be.

Charlie: The blog pages would most likely be created using a pre-built page in your example, Mike. There shouldn't be a need to edit the page, otherwise creating 500+ pages would take forever. I would also handle blog pages specifically using a bucket. 

Mike: I guess I haven’t come to this same conclusion.

Jackie: To clarify, is the assertion that explaining SXA to content editors is easier, or that using it is? Because those are two different things.

Mike: My position is that if you’re learning editing in Sitecore, SXA is the way to go. It will provide you with the ability to know what the page will look like as you build. It will also explain a lot of the concepts included in a Sitecore page (read: the components under "page structure"). If I was creating a fresh landing page, editing existing pages or really any activity that requires more flexibility, I would use SXA hands down. If it was a massive content site and I'm making large number of article pages, SXA would slow me down. Knowing the placeholder names, to me, is just like knowing I must place containers and what not. That said, though, I would classify *myself* as one of the content editors resistant to change. I know how to do what I want to do and changing that slows me down.

Andy: I agree. I do think there is a time trade-off though. An inflexible static content template with static content fields is very easy and quick for me to fill in as a content editor. No time loading a "page builder", no time creating layout elements, no time configuring component variants. My lack of power to control the layout makes it very easy and quick to fill in raw content. It’s the classic "with great power comes great responsibility". The powers you get from the page builder are rad though, so there are tradeoffs.

Mike: That's exactly how I look at it. It really depends on the types of pages I’m creating and the direction I have in terms of content. If it's just copy/paste content work then I want speed. How do developers feel about more configuration and less coding? Back end at least. I'm interested to hear that take.

Charlie: I'm not all that thrilled about it. I had a lot of problems with SXA [1.1] when I went to install it on production.

Una: Configuration wise, documentation is really missing how SXA should be configured on different environments. Coding wise, as in everything: pipeline all the things! If it is in the way or something custom is needed, I don’t see that SXA stops you from coding. BUT you do need to know how SXA works code wise. Documentation in that regard is limited, but I’ve been dealing with SXA since 1.1, so I already know where to find most of the things I need. For a newcomer, there is a learning curve.

Jackie: That's a point worth noting too; SXA is a product that's in active development. The latest version was released a few weeks ago. For those who've had a chance to play with it, are there new features or fixes that really stand out?

Mike: In SXA 1.6 they released Snippets. That is super cool. Svetlana wrote up a nice blog on that. I'm a big fan of macro strategies for content. With snippets we make composites or groups of renderings, so I can quickly add them across pages. It's a bit more flexible than partial designs.

Una: I love the new wizard for creating renderings. Saves me tons of time.

Andy: I know the most recent SXA releases have improved some aspects for front-end developers, such as more flexible grid system options. But the time/effort implications of SXA for front-end development are tough. Like all CMS "page builder" systems with out of the box components where control of the HTML is taken out of the front-end developer's hands, SXA increases front-end effort. There's no way around that. Once a front-end developer has a lot of experience with SXA and a great working relationship with the Sitecore developers they're partnered with, they might be able to get front-end development time back down to the same amount of effort you'd normally need on a standard project where the front-end dev gets to control the HTML. I think you are adding some extra front-end development challenges in return for other benefits like robust powerful content editing capabilities that integrate with Sitecore analytics and personalization. There are different ways of approaching your design and front-end dev process to make those aspects work more smoothly with SXA.

Jackie: Can you expand on that? I'm really interested in that take.

Andy: Well, I think you achieve the best time savings with SXA whenever you can leverage its out of the box components. Agencies experienced in SXA will approach the design process that way from the beginning, which is an important strategy. On the SXA-based projects I’ve worked on, designers wanted to know what components come with SXA, how they looked and behaved by default so all that could be leveraged in the designs. Every time you can achieve that efficiency, aligning the designs with what SXA already does, you save time and money. The other side of the coin: if your design team designs from scratch (as is commonly the case), it often turns out that many of the design elements are hard to achieve with out of the box SXA components. To be clear, this would be the case for any system that comes with a list of out of the box components. 

Una: I prefer the other way around when it comes to the design: don’t design for SXA, bend SXA to work for you. That is the approach I am taking now. When it comes to front-end, the developer needs to have couple of projects of experience. I think it’s easier for back-end.

Andy: Us front-end developers would definitely appreciate that approach, Una. Any time we get to decide the HTML is more efficient for us. It’s kind of like asking a mechanic if he can build you a car with some specs - the mechanic will probably say yes. But the effort changes if you show up to the garage with a truckload of parts and the mechanic needs to stick to those. I've experienced the same trade-off with "page builder" solutions with several different CMS systems.

Una: For the above approach to work, I would need front-end next to me when making variants and other rendering stuff. HTML can be manipulated to a certain extent, and it’s much easier now to impact the view.

Andy: I think that brings up an important point. It is beneficial to have good communication and coordination between Sitecore and front-end developers when working with SXA. Sitecore developers are creating rough drafts of each component and handing that to the front-end dev as a starting point, which is different from what most developers are used to. You really need to collaborate directly.

Una: Can I quote you on that, Andy?

Jackie: The cooperative aspect of SXA is something we haven't really touched on, but it's worth discussing. SXA means teams really have to work together.

Una: When I’ve worked on trainings, front-end and back-end were next to each other and it helped enormously. Those guys did a terrific job.

Andy: Ideally, that is how the development process would always work. But in real life server-side and front-end dev teams are often kept separate, sometimes even provided by different agencies on the same project. Collaboration is especially important with SXA because the server-side and front-end devs will need to iterate back and forth on a few details to get each component completed. You'll be working together to decide if any out of the box component can suit your goals, and if they don’t you'll work together to accomplish the specific HTML and functional customizations that are needed.As a side note, having a menu of all the out of the box components with text descriptions, functionality descriptions and wireframe images would be really, really helpful to designers working on SXA projects (hint hint Sitecore...)

Jackie: Coming to the end of our discussion, so one last question. What's one thing you wish everyone knew about SXA?

Una: I wish companies would give SXA a try, even if they already have their frameworks.

Mike: That SXA is an editor that lets you do more than simply build pages. Companies should invest the time to really make it what they need. If you make it a tool within the usual toolbox, your teams can do many things much more rapidly, like wireframing in SXA for landing pages you don’t have a page design for, multiple page designs in case you want to throw something wild together, and partials or snippets for a macro content strategy. They’re all benefits companies could take advantage of if they really dive into SXA. It requires patience to truly make SXA what you need it to be, but long term you'll see returns.

Andy: I'd say SXA is a tool that unlocks powerful features, but should not be approached like a quick drop-in add-on. For maximum success you really need to understand its ideal workflow. That knowledge should trickle through your whole project including the design process.

Keep in Touch and Stay Informed

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