A recent addition to the Sitecore ecosystem is a formal release of recommended practices from Sitecore. Collectively known as Helix, this set of design principles and conventions for Sitecore development provide some much needed guidance to the community.

There is a lot to read in the documentation, but here are the quick wins I would suggest everyone could take from Helix.

No more excuses, Sitecore items need to be managed (like code)

A Sitecore solution is dependent on templates and many other items found in the Sitecore content tree. In order to support repeatable testing and deployment those Sitecore items must be managed.

“Just as files and Visual Studio projects are a part of our Sitecore implementation, so are Sitecore items.” (http://helix.sitecore.net/principles/sitecore-items/index.html)

Helix draws a distinction between two types of items: Definition items and Content items. I’m not sure that this covers all the nuances of the types of items we find in the tree, but Helix attempts to separate them as Definition items being things like renderings, templates, lookup items and Content items being items which are managed by editors and are owned by the production environment. 

Some will argue that only Definition items should be source controlled, but depending on the stage of your project – like a large scale content migration – Content items might also be included. 

Our favorite tool to address this recommendation (and many other) is Team Development for Sitecore (http://www.teamdevelopmentforsitecore.net)

Configuration Strategy

Configuration can mean a lot in the context of Sitecore. It can start as simple as web.config, patch files, and items in the Sitecore tree and grow to encompass broader settings in Windows, IIS and the network. Helix does not address the broader context – a miss I think – but enumeration of configuration Scope is something that we often see missed.

Figure 32 from Helix:

Sitecore Helix What all developers and architects should take from Sitecore's design principles

Some tools that may help you address these points of guidance include:

- SlowCheetah (https://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5) to create Role and Environment transforms on .config files. With a .config file in the solution you can define transforms that will adjust the contents for different roles (content management vs content delivery) and environments (QA, UAT, Production).

- Multisite/multitenant architectures found in Keystone (www.fasterwithkeystone.com) and SXA (https://doc.sitecore.net/sitecore_experience_accelerator

More on configuration and settings from Helix: http://helix.sitecore.net/principles/configuration/index.html.

Page Layout

This is of course the majority of what the marketing team and end users of the site actually use and see. There are a lot of specifics on implementation level details but the goal statement is probably the most important:

“The balance between flexibility – allowing the editors to dynamically construct the pages by placing feature renderings in placeholders – and consistency – having a coherent visual design and user experience across pages – needs to be found in all implementations. Swing too far in one direction and the user experience may be hurt, swing too far in the other direction and the business might end up with a rigid and inflexible solution that frustrates users, or lessens the return of investment by not supporting the full capabilities of the Sitecore platform.”  (http://helix.sitecore.net/principles/layout/index.html)

Striking that balance is not an easy task, but I think the Helix documentation misses out on the important elements that play into that balance. Perhaps the writers assumed everyone already considered:

  • How do you intend to resolve the usability conflict created by dynamic placeholders (because everyone uses them) and compatible renderings?
  • Does the presentation conform to the accessibility laws that the site is subject to? Chances are there are one or more depending on jurisdiction and industry.
  • How does the presentation layer impact search engine performance and overall search engine optimization factors?
  • How about performance (speed of rendering)?

Conclusion

There is a lot more to the Helix material, so I do encourage you to read it in depth at http://helix.sitecore.net/. I look forward to seeing Sitecore evolve this valuable guidance, with input from the community.

comments powered by Disqus