Many agency sided developers and functional designers that have experience in working with Sitecore will go ‘doh’ reading this article title. Though, many companies who are thinking about integrating their online platform with Sitecore should wonder why. Well here goes:
Ask three different agencies to build your platform briefing in Sitecore and it is likely that you will get three different implementation strategies.
Sitecore itself has an open architecture that is as open as you could imagine. It is kind of a DIY CMS package, where all parts have been delivered, but you decide how to compile it. As every piece of functionality can be broken down in to individual items, all these items can be applied differently, can be altered or extended. Ask three different agencies to build your platform briefing in Sitecore and it is likely that you will get three different implementation strategies. They will have one thing in common though: your platform will be very modular.
The way Sitecore builds up a webpage is the main reason for this. Sitecore lets developers and designers divide a page in certain areas, so-called placeholders. Content editors – with the proper user credentials – can place different types of page elements in these placeholders. Your marketing department, together with your agency’s graphic- and UX designers come up with the set of types that your online platform needs. Think of featured news articles, social media boxes, web shop snippets or maybe just one image.
Developers or architects will transform these ideas and designs into working components in your Sitecore CMS. In Sitecore’s in-line editor – the Page Editor mode – you will visually see the defined page area’s in which you can dynamically place the newly built components. This is the foundation of Sitecore’s way of operating.
After you select what type of component should go in which page area, you need to select what content will go into these components. Wait, hold your horses. I do what now? I will explain.
Sitecore has two layers if you will: a content layer in which all copy and assets are stored and a presentation layer in which you decide what goes where and how your content is presented. What I have discussed in this article thus far is only in context of the presentation layer – the how. The content layer is your classic list of pages and content nodes holding copy, images, files and other system settings – the what.
Let’s say you want to add a rather simple paragraph box to your homepage, showing information on an interesting offer. It will hold an image, a title, a piece of copy and a call-to-action hyperlink. You’d start by adding the layout of the paragraph box page element and place it in the page area you’d want to place it in. For now, you will add a new content item in which you specify the image, the title, the copy and the hyperlink. It’s all pretty straight forward.
It becomes interesting if you also have an Offers page, in which you want to place the same box with the exact same content, but now in the sidebar. Instead having to enter the same content over and over again, you select the same page element type and place it in the sidebar. As it should contain the same content as the one on the homepage, you select the same content item you have just created. You can repeat this for all pages you want to have this offer in place. You can reuse your content everywhere in your website, without ever having to enter it over and over again.
Having your content centralized also helps you being efficient in content changes: if you change the content at the origin, it will be changed everywhere you have reused that content node.
A disclaimer should be placed on behalf of front-end development: if the same page element type needs to be placed on many different page areas, the HTML and CSS needs to be compliant as well. I can therefore highly recommend keeping the communication channel wide open between developers and content editors during the development phase of your Sitecore integration!
Same content, different lay-out.
Components can be very similar to one other. Like the image below, page elements may visually come in many different forms. What is interesting though: they all require the same content. In Sitecore, it can be configured what page elements are compatible with one another and what kind of content they should hold. This makes that you could not only place the same content in multiple page areas, but also in different forms or shapes. In Sitecore’s Page Editor mode it is very easy to move components to different area’s or to change their presentation with other compatible presentations.
Ante up! This modular way is precisely where the Sitecore Digital Marketing Suite (DMS) comes in to play.
Till thus far, I have spoken about pages that have page area’s with can hold page elements or components that may be compatible with other presentations (presentation layer) and may hold different content sources (content layer). What if we’d bring multivariate testing to the table, or content personalization?
With Sitecore DMS, among other interesting functionalities, you can apply A/B or multivariate testing to your online platform. Rule-based personalization – showing tailored copy and photography based on a user’s behavior and characteristics – is another.
Essentially, multivariate testing is nothing more than comparing page elements as they are displayed in different forms and/or with holding different content. This is where this modular way of working is essential again. Sitecore lets you create multiple content versions after which it will switch between these versions. Afterwards, it will show you the analytics to see what combination of presentation and content has performed best.
Personalization is based on the same principle. Based on the behavior and the characteristics (referrer information, social media connectors, click path, etc.) of a user you will show personalized content in which you try to provide that user exactly the information he or she needs in its current state of their customer journey. Functionally, just like multivariate testing, this can be broken into a simple methodology: you create different content for the different persona’s you want to serve, and Sitecore will deliver that. Based on different rules, Sitecore will provide the right content to the situation, e.g. ‘if the user likes mountain biking on Facebook, show mountain bike offers in the sidebar offer panel’.
Doesn’t all these options make my platform vulnerable or complex?
Having many different types of pages, page area’s and page elements that may or may not be compatible with each other may seem very daunting to you. But, this is flexibility in its optimal form. Although that is what content managers typically like, it is not always the most efficient or may jeopardize the quality of copy if you don’t apply all options properly. Furthermore, the more options are given, the more complex it gets. Advanced training and content management workshops are therefore not uncommon.
Luckily, Sitecore provides a good security measurement to constrain this flexibility. Hypothetically, you could create a paragraph and move that to the page area ‘Navigation’, but that would not make any sense. Therefore, it can be configured in Sitecore what page elements may be created in specific page area’s and if they are even editable at all. Also, it needs to be configured what page elements are compatible with each other, so that there cannot be a mismatch between one presentation and the content that needs to be placed within.
It also makes it much simpler for your content managers: they get to place whatever they are allowed to and are not confronted with any options that would not make any sense. It keeps the interface nice, tidy, and simple. Personally, if I would configure Sitecore for you and you would find it too complex or inefficient, than I didn’t do my job properly.
Is this in-line editing in the Page Editor mode necessary?
Some of the clients that I work with tend to deviate from this modular way of working. The main reason that they typically mention, is that the Page Editor mode tends to be slow at times. They also find it more convenient to add just content to the system, whereas code from development would automate the lay-out based on that content.
Although I agree with some aspects of that argument, I would strongly not recommend proceeding that deprecated road. Although there are some backdoors and workarounds which would allow editors to switch panels to different page areas or to apply multivariate tests or personalization, this is very complex for your typical content manager. Without technical know-how, many risks are involved as something as a small typo could break down your page or even website.
Sitecore will follow their philosophy of editing presentation and content in the Page Editor mode even more and more in the next Sitecore versions. This argument may be worth looking at, as you don’t want to create a deadlock for yourself of not being to properly upgrade over time without extensive costs involved.
Reply