Two of SXA’s key benefits are improved project cadence and less reliance on development. Achieving these goals often means changes in roles and responsibilities.
Development doesn’t necessarily mean coding
With SXA, some of the implementation work that would otherwise be done in back-end code is now done in the Sitecore UI. That doesn’t mean that code is written in a Sitecore UI, but it does mean that some things that would have otherwise required code are now either done in, or supplemented by, activities in the Sitecore UI.Once upon a time, the Sitecore UI largely insulated the person in the chair from technical “stuff”. Now, quite a bit of that technical stuff is managed in UI. Structuring components was once done entirely in code, now this is done largely in Sitecore. You’ll find yourself declaring element tags and CSS classes, creating data queries and using substitution tokens, and structuring things akin to models and markup. But just because it’s managed in UI doesn’t mean it doesn’t require a technical thinker.
Although much of the methodology shifts from code to configuration, developing functionality in SXA is conceptually more akin to development than content management. Just like in coding, an understanding of what can be done and how things work, leads to effective solutioning. Your technical staff is going to change where and how they do a lot of this work, and the big benefit is that many things that would otherwise have required a code deployment now just require a publish.
This will require a shift in thinking for both I.T. and Marketing. In the early days of CMS it was often hard for I.T. to accept that content management was now a production activity; now they must accept that more things that have been traditionally subjected to development protocols are now becoming production activities as well.
Front-End in the loop
The role of the front end developer isn’t just coding, and it isn’t just design. It’s some of both and other things besides. Since SXA is a framework that manages the methodology for developing both structure and style, the front-end developer’s work becomes part of the SXA flow.Changes to HTML structure are done directly in SXA (or at times, in back-end code). This may be driven by the need for new renderings, or by imperatives the styling process. As wireframes and content are developed, the entire site (or portions of it) are exported to a ZIP file, where designers and front-end developers extend CSS and JavaScript and apply styling using their preferred tools. Sitecore’s Creative Exchange re-imports this zip file, detects changes to styling, and applies them to the system. The styling methodology is constrained by how the SXA framework operates (for example HTML structure and content can’t be modified, and existing class cannot be removed), and SXA injects comments into the HTML to direct developers as appropriate.
If desired, teams can use “Creative Exchange Live” to fully automate the export/import loop. Creative Exchange can be triggered by a Continuous Integration server, integrating code changes into the main branch, and to test changes early and often.
Next: Which Way to Go?
Home: Understanding Sitecore SXA
