Sitecore Experience Accelerator - SXA

Note !!! I have moved my blog to https://pramisoni.wordpress.com/ . Please Visit https://pramisoni.wordpress.com/ for old and new posts.

Hi Friends ,

From last few days, I was reading about a very interesting topic (Sitecore Experience Accelerator).

From last few month, it's getting popular in Sitecore community and discussions. I am sure from some of us must have already started working into this  .   

I found it's interesting to me and thought to share my experience with you .

So What is Sitecore Experience Accelerator ( SXA) ?

It is fully integrated into the Sitecore editing function, Experience Accelerator (XA) reduces your time to market by allowing content teams to design, assemble and deploy web content across channels with fewer development resources.

This is a theoretical definition which you may read into details from Sitecore website .

Sitecore Experience Accelerator come with some new feature and best practices . In my previous post, I have written about Helix best practices . Sitecore Experience Accelerator use helix practices by default

1. Drag-and-drop page assembly
2. Dynamic wireframes
3. Best practice by default
4. Separate IA from design

Let's go into some practicality  

How to configure and work with this new concept ?

Steps to configured

1. Install Sitecore Experience Platform 8.2 rev. 160729 (8.2 Initial release).

2. Sitecore PowerShell extensions (full 4.1 for Sitecore 8) from https://marketplace.sitecore.net/Modules/S/Sitecore_PowerShell_console.aspx

3. Download Sitecore Experience Accelerator 1.1 rev. 161004 for 8.2 from https://dev.sitecore.net/Downloads/Sitecore_Experience_Accelerator/11/Sitecore_Experience_Accelerator_11_Initial_Release.aspx and install it as package installation Sitecore

Note : This required Sitecore license include ( Sitecore XSA )

To Check XSA license are included , Go to Sitecore - Control Panel - Click on “Installed licenses”

And see if you have “Sitecore.SXA” listed in agreement as in attached screenshot.

 

SXA separates structure from design, so front-end designers, creative designers, content authors, and developers can work in parallel and you can deploy and maintain multiple sites quickly and cost-effectively. Once a basic user experience plan is in place, everyone can get started on the platform. For example, the content author can start entering the content in the wireframe environment, while the front-end developer works on the theme, and the developer sets up the data templates.

XA uses the following concepts:

• Toolbox
• Grid and column layout
• Pluggable themes
• Page designs and partial designs
• Creative Exchange
• Assets Optimizer

In this post, I am more concentrating in the demonstration of how its work . For more theoretical guideline follow Sitecore official site  Experience Accelerator (XA) . In rest of this post, you will see more practical example and screenshots .

Create a tenant and a site

The SXA content architecture includes tenants and sites. SXA supports multi-tenancy, which means that you can run multiple sites on a single instance of Sitecore. Each tenant can include multiple related sites

Create a new tenant.

When you will try to create new tenant you will get the list of the feathers to be selected . Here you can choose which feathers is required to be available on the new website . I will suggest keeping all for learning.

After click on ok “New Tenant”  folder will be generated in 3 location , which will have a specific setting of that tenant and sites reside inside of that tenant . This “New Tenant” folder will have default template structure for pages and setting creation  .

After creation of tenant now we need to create sites inside of talent .

The new site will have the list of options to be configured  . When you will click on site a new configuration window will be appeared and will have 3 Tabs to configure site setting ( General , Feature , Theme ). General option is to configure hostname , site name etc. See in attachment for General Setting.

In feature option , a list of features to be configured for that site will appear which is nothing but available rendering options for this site . The only selected option will appear as part of available rendering option in site . This selection will affect on 2 places

1. Tool Box in experience editor
2. “Select a Rendering “ window In Experience Editor when click “Add Component ”

The third and last tab , Theme , it will give the option to choose a theme . Sitecore Experience Accelerators provide default theme “wireframe “ .  A theme can be added more .

Sitecore Experience Accelerators support multisite . These are the basic setting that requires configuring a site in Sitecore Experience Accelerators.

Let's move to the site structure and options .

Here will talk about all options which come default when we create a site  .

1. Home :  This is the home page for the site and will have subsequence pages of the site .
2. Media :  Will contain media item for the site
3. Data : It will come with all empty container to keep data source . Example : Accordions , Carousels etc . This will have an impact based on the feature/ Rendering we have selected while creation of a site as described above . That means only selected rendering will have Data container folder to keep data source .This can be modified of course .

4. Presentation : There are a bunch of options are available and every option has their own purpose and meaning . Will describe some of the important options here .

 

4.1   Available rendering :  This option will provide all the available renderings into groups . This option will also have an impact from the feature list , only selected features option , while creation of the site , will be part of the available rendering .

Let's go into details

As said , All renderings are grouped into based on behavior .

Let's take the example of Navigation as shown in the screenshot .

Here I consider navigation is a group and have multiple rendering available default based on behavior.

I really liked this option as it gives a clear separation between renderings based on their behavior and makes work very handy as it's give same option in toolbox and Experience editor.

4.2  Page Design : Page design will give you flexibility to manage

1. Design
2. Theming .

It gives the option to map design( Layout)  with page type ( Template ) . SXA provide the option to choose addition partial design/ Layout  apart from the one from the main layout in presentation . In screenshot , Home Template mapped to “default Page design /Partial Layout ”

And page Template is mapped to other “page design/ Partial Layout  “

Let's look inside more

What is inside of Page Designs option  ?

As shown in screenshot , page design option will have option select Partial layout which will be part of the page design and provide partial layout apart from the main layout .

4.3 Rendering Variant :

SXA comes with a set of default renderings and rendering variants. Rendering variants are configurable adaptations of the default renderings. To further encourage reusability, designers and front-end developers can also create new rendering variants. This gives authors more options in the way they present their content.You can create your own variation of a rendering by adding a variant in the Content Editor. More detail is available in Sitecore site Sitecore Experience Accelerator . I Really found this is very handy . In my previous post Deck Modifier , we used a similar concept but not exactly same and it was without SXA . Somewhere I can relate with to as a rendering parameter for my own understanding .

For selecting a variant you need to go to Experienced editor and select a variant as shown in screenshot .

And here you can see how it will look in Experience editor . Remember accurate field name is very important . Variant will be applied based on the field name .

4.4 Style : Sitecore accelerator comes with a default set of styles with wireframe themes . Styles can be customise added / Deleted / Modified .

So that means if a class can be created and can be available for rest of the rendering based on the selection in Allow rendering .

Let's see the example .I have created a demo Style and selected bunch of rendering where this new style will be available .

So that means My “Demo Style” should appear in all the rendering which I have selected .

Now let's move to the Experienced editor to see how it work .

It will appear in “Control Properties” after click on “Edit component property” while adding a Component from experience editor .

We forgot to talk about template and layout structure in SXA. Let's go into template structure first . I have highlighted 3 major part here . The feature , Foundation, and Project .

Feature :The Feature layer contains concrete features of the solution as understood by the business owners and editors of the solution, for example, news, articles, promotions, website search etc.

Foundation : Conceptually, it is helpful to think of all the frameworks and software you rely on in your solution as foundation modules. This includes the Sitecore platform,NET, and other technology frameworks .These are typically very stable modules.

Project : The Project layer provides the context of the solution. This means the actual cohesive website, such as the page types, layout, and graphical design.

So whenever you create a new tenant it will automatically generate a default structure as shown in screenshot inside of project folder .

These folder structure has been generated based on helix principles .  I suggest looking into helix principles also for better understanding about SXA structure .

Sitecore : Helix and Habitat

Note !!! I have moved my blog to https://pramisoni.wordpress.com/ . Please Visit https://pramisoni.wordpress.com/ for old and new posts.

From the last couple of days, I was reading about Sitecore Helix  Principles .

While reading into detail I thought to write a small article which summarizes the agenda of Helix Principle . This small Article may be useful for them who is already working in Sitecore and working on Component-based structure . Most of the contents have been taken from original site Helix  Principles.

Helix is a set of overall design principles and conventions for Sitecore development.

Here helix is talking about lots of design principles which you will come across when read the post

• Single Responsibility Principle
• Common Closure Principle
• Stable Abstractions Principle

Few more common terms which you will come across multiple time

• Component-based Architecture
• High Cohesion and Low Coupling

Helix focus on listed design principles that should be used during software or project development . This principle mainly focus on reduced dependencies between software modules.How modules should be structured and how individual sites should use these modules . Helix is a set of recommendations for making your Sitecore project as easy to create, test, extend and maintain as possible.

So if Helix is a set of recommended overall design principles what is habitat ?

Habitat is a real Sitecore project implemented on the Sitecore Experience Platform using Helix

Habitat is a Sitecore solution example built on a modular architecture. The architecture and methodology focuses on:

• Simplicity - A consistent and discoverable architecture
• Flexibility - Change and add quickly and without worry
• Extensibility - Simply add new features without steep learning curve

There are three main topics important to Helix and modular architecture:

Dependencies

which describe how feature and functionality in the solution relate to each other.

Layers

which control the direction of dependencies and thereby assure a manageable solution.

Modules

which define the isolation of features and functionality leading to greater discoverability and simplicity in the development process.

Helix describes the overall architecture of your Sitecore solution and thus communicates some guidelines and conventions which should be durable and flexible enough to be applied to any Sitecore project or business. The architecture pattern described by Helix is often referred to as Component-based Architecture or Modular Architecture.

The architecture principles and conventions defined in Helix focus largely on macro architecture, i.e. how the complete solution is put together for maximum productivity, quality and longevity.

Helix focus on High Cohesion and Low Coupling

1. Dependencies

This is both important in the micro architecture – how you break down functionality into methods, classes, class inheritance to Controlling dependencies throughout a solution

One of the fundamental principles of object-oriented programming is High Cohesion and Low Coupling. High cohesion relies on breaking the solution down into the right parts with logic that belong together – in Helix referred to as modules – and low coupling relies on keeping the number of dependencies between the different parts down to the absolute minimum.

2. Layers  

 2.1 Project Layer

 2.2 Feature Layer

 2.3 Foundation Layer

The layer concept in Helix supports the architecture by making the dependency flow completely clear everywhere in the solution

Layers helps control the direction of dependencies – the importance of which is described by the Stable Dependencies Principle or SDP, which is one of the cornerstone principles in Modular Architecture:

This principle tells us that a module should only depend on a module that is more stable than itself. If dependencies are not controlled, then you can end up in a situation where a change will unintentionally affect seemingly unrelated parts of the solution

The Sitecore Architecture Conventions defines three layers: Project, Feature and Foundation. Each layer have a very clearly defined purpose. In order to structure your Sitecore implementation properly, it is important to understand the principles behind each of these.

The three layers are defined in Visual Studio as Solution folders, in the file system and directories and in Sitecore as corresponding content type folders.

These are the typical places where layer folders are defined in Sitecore:

• Master:/sitecore/system/Settings/[Project|Feature|Foundation]
• Master:/sitecore/templates/[Project|Feature|Foundation]
• Master:/sitecore/templates/branches/[Project|Feature|Foundation]
• Master:/sitecore/layout/renderings/[Project|Feature|Foundation]
• Master:/sitecore/layout/layouts/[Project|Feature|Foundation]
• Master:/sitecore/layout/placeholder settings/[Project|Feature|Foundation]
• Master:/sitecore/layout/models/[Project|Feature|Foundation]
• Core:/sitecore/templates/[Project|Feature|Foundation]

2.1 Project Layer

The Project layer provides the context of the solution. This means the actual cohesive website, such as the page types, layout and graphical design.

The Project layer is typically small and contains few modules,

In Habitat there are two modules in the Project layer: Habitat and Common. Habitat represents the actual Habitat website, and therefore connects the features and page layouts in a way that fits the requirements for this website. The Common module paves the way for a multi-tenant implementation by defining some of the shared templates and settings between tenants

2.2 Feature Layer

The Feature layer contains concrete features of the solution as understood by the business owners and editors of the solution, for example news, articles, promotions, website search etc.

Each Feature layer module has to strictly conform to the Common Closure Principle.

This principle ensures that changes in one feature do not cause changes anywhere else, and that features can be added, modified and removed without impacting other features.

2.3 Foundation Layer

The lowest level layer in Helix is the Foundation layer, which as the name suggests forms the foundation of your solution. When a change occurs in one of these modules it can impact many other modules in the solution. This mean that these modules should be the most stable in your solution in term of the Stable Dependencies Principle.

Conceptually, it is helpful to think of all the frameworks and software you rely on in your solution as foundation modules. This includes the Sitecore platform, .NET and other technology frameworks such as Bootstrap, Foundation, jQuery etc. In the context of your implementation, these are typically very stable modules but when they do change.

A single Sitecore implementation can end up consisting of a large number of modules and this can lead to technical management issues.

Good rules of thumb are that your architecture should always have higher priority than any tools .

Each module has the following structure:

Module Name  

code          

serialization {Contains the serialized data from Sitecore}
Tests         {Unit or other test types for the module}

Modules

The concept of modules in Helix is derived from the concept of components in Component-based Architecture

Keep in mind that in Helix, modules are business-centric. This means that they should relate to business objectives and group together multiple technology entities that refer to this objective

For this reason, the breakdown and naming of modules can be one of the most challenging parts of adopting Helix

Helix force “The Single Responsibility Principle “ should always have higher priority than any management or tools related issues

Ex : Feature/Accounts : This feature handles everything involving user accounts: login, registration, xDB integration, user profiles, etc.

But modules are always grouped by their logical connection to a module – and never by type.

Helix principle force to Common Closure Principle(“what changes together should live together”) , we need not only to make it obvious which items in Sitecore belong to which modules, but also to manage and version the items alongside the code in these modules. But interesting thing to be noticed here helix only force to keep sitecore related ( Template , Item , Rendering ) and correct code as one module or group in Visual studio  but at same time helix follow conventional approach to  manage sitecore items .

• /sitecore/templates/[Project|Feature|Foundation]/[Module]
• /sitecore/system/Settings/[Project|Feature|Foundation]/[Module]
• /sitecore/layout/renderings/[Project|Feature|Foundation]/[Module]
• /sitecore/layout/layouts/[Project|Feature|Foundation]/[Module]
• /sitecore/layout/placeholder settings/[Project|Feature|Foundation]/[Module]
• /sitecore/layout/models/[Project|Feature|Foundation]/[Module]

Helix use unicorn for serializing items

So here helix is talking lot about separation of module so what about  inheritance concept which we do when we create a base template and inherit this template to other templates without concerning which module that pages type is going to be used .

The architecture does not have the concept of a single common base template across all templates – which is a practice that is commonly discouraged as it will often lead to bloated items with unnecessary fields ( Helix concept believes) .

Multi-site and multi-tenant

Tenants are groupings in the business organisation that need freedom and autonomy to define and manage their own sites, channels and data.For example, this could be multiple departments in an organisation with separate websites, but a willingness to collectively define and share the features available on these sites in order to reduce the cost of development and maintenance.

Although Sitecore offers a great platform to support multi-tenancy in the software, there is no predefined tenant context in Sitecore.This means that the borders between what is shared between tenants and what can be defined autonomously is largely for you and the business to define. This includes content hierarchies, content repositories, media, workflows and more.

It is recommended that each tenant in a Helix compliant implementation has its own project layer module, i.e. that each tenant has the freedom to define its own set of datasource and page type templates (see Template types) as well as its own overall page layouts and sub layouts. If multiple tenants share templates or layouts, it is recommended to have a shared project layer module to host these entities. This gives the flexibility for a tenant to use shared as well as specific page types and layouts in their site or sites.

For know more details about tenant

The Habitat example site implements the Foundation/Multisite module that defines multi-site and multi-tenancy specific functionality for the feature modules

 

Front-end technologies

The front-end technologies used in the Habitat example site are introduced in the Foundation/Theming module and can therefore be shared across to all foundation, feature and project layer modules.The main front-end technologies introduced in Habitat are Bootstrap, jQuery, Bower and Sass. Furthermore,The theming in the Habitat example site is primarily based on Bootstrap. The module Foundation/Theming implements the base CSS theme based on an Atomic Design approach.

For detail Article check Helix Official Guide