Wednesday, March 27, 2019

Understanding Sitecore SXA: Prescriptive, Yet Flexible

Previous: Improved Project Cadence

Many marketers and technologists have found that their perspective on a large project can change rapidly, as the level of effort and learning curve become increasingly clear. The envisioned scope, schedule and budget are all threatened, as the imagined methodology and cadence meet reality.

SXA tackles this dilemma by providing a proven structure, framework, and methodology. The aim is to simplify processes, increase collaboration, shorten timelines, and smooth the path to success. Naturally, the maximum benefit is gained by a comprehensive adoption, but SXA can be used in an opt-in fashion, utilizing some of its features and replacing others with more conventional approaches.

By embracing all of SXA, organizations achieve the maximum benefit that they seek from a prescriptive, out-of-the-box framework. For many organizations, however, there are aspects to the architecture or build process that need a more custom approach.

Going All In

Adopting SXA to its fullest doesn’t mean giving up customization. Design customization is an essential part of an SXA build. Customizing CSS, building multiple themes, and extending the client-side structure are all common activities in an SXA build.

Page structure are actually more flexible with SXA than a typical conventional build. Content editors are able to drag-and-drop renderings, choose from more focused data sources, and adjust column widths. Also common is the use of Rendering Variants, to change the structure and appearance of components — without requiring code deployments!

SXA’s preferred project cadence solves a common pitfall. When design collides with content, it often becomes necessary to adjust, when styling designed for best casecontent collides with real world content. In the SXA model, these collisions are detected earlier, and remediated faster than with a conventional build.

In an all-out SXA implementation, the design/style/construct process is shortened, but changes from conventional expectations.

Wireframes are developed directly in Sitecore. They are exported as packages with HTML, CSS and script, organized in an orderly layered stack based on themes. Designers and front-end developers then style these wireframes, by extending and modifying the CSS and script (for the most part, without changing the HTML). Their work is imported back into Sitecore, where their theme(s) are applied to the site(s) that have already begun to take on content and structure.

This process can be iterative and branched. The export/style/import process can iterate, without necessitating radical changes to the existing work. In fact, Sitecore SXA provides “Creative Exchange Live”, that uses the gulp toolkit to bring design into a dev-ops model for continuous integration. Content editors continue to develop content and construct pages while the styling process iterates, shortening the project timeline and providing more real-world content to help refine the styling.

Multiple themes can be developed within or across sites, allowing the same components and structures to be presented differently simply by selecting from the different themes. The compounded power of reusable components with customizable themes and development-free customization, creates a force multiplier that can dramatically improves time-to-value.

Deep customization when needed

SXA ships with an impressive set of components that cover most of what the core of any site will need, and through the use of “rendering variants”, new renderings can be created without requiring coding.

Using these components out-of-the-box means (for the most part) working with the HTML as provided and styling entirely with CSS and script. An implementation can replace the HTML of all or some of these components and add new ones, but this requires requires a back-end development process more akin to a conventional build. Custom HTML is cut up and used as prototypes for c# developers to create new views, which replace default views or are registered in SXA as new components. Changes to the HTML require code deployments after a round trip through this back-end development process, which can slow concurrent content development.

Next: Changes to Roles and Processes