“I hate Sitecore.”

As a developer, I have heard that many times.  But it’s usually not true.  It was probably not organized, configured, or explained logically.  Or the dev team never took the time to see the post-launch care through the eyes of the non-dev team that was going to inherit this system.

Sitecore is a very complex and complicated system.  It can be overwhelming for new users (content authors).  As developers, we can shape the users experience and perception of the tool.  Many users that complain about Sitecore don’t really dislike the tool itself, they dislike their implementation and how their instance was built.   

It is easy to build a component in SXA, give it a data source folder, create the rendering variant, put it on a page, show it to QA and close the work item ticket as done.  It is a completely different thing to think about how the content author will use this component. How will they choose this component to put on a page?  How will they differentiate it from another component?  Where will they put the datasource item?  Do they understand the concept of datasources?  One of the great things about Sitecore is content reusability.  You can create a piece of content and use it on multiple pages.  When you update the content later, it updates on all pages where it is used.  But how often is content actually reused in real life?  Header and footer links of course.  But most of the time, the body content on page X is never used on another page.  

Content authors often do not think about pages as blocks of content.  When they come to us as developers with an issue, they point us to a url and say “there is a problem on this page”.  How do content authors look at their site with the available tools and figure out what is the right datasource item to change?  As a knowledgeable Sitecore developer, I recently spent a couple of hours to find the correct datasource for a button in the header.  I had to hunt through designs, partial designs, child items of a partial design, presentation details of partial designs, related items, snippets, presentation details of snippets, and child items of snippets.  I was able to find the datasource, but even I was frustrated.  I can imagine the client trying to find the same button with less knowledge and becoming completely frustrated AND likely not finding the correct item. 

I like the concept of the site/data folder.  But I don’t think it should house all the site’s content.  It makes it very hard for the content author to point to a page and find the related content.  I would like to see the site/data folder used only for global content and content that is truly used on multiple pages.  Then put content local to a page as child items to the page itself. 

Another problem is the media library.  It is even easier to lose control over the media library as a site grows.  Sitecore doesn’t impose or suggest any structure.  Moreover, the media library is THE place to store media.  It is not possible to store a media item as a child of a page.  It is often no ones “job” to manage the media library.  If a content author is not able to quickly find the image they need, they will often upload a new copy and link to the page they are working on.   

How can we make life easier for content authors and provide an enjoyable experience to create a positive view of the tool? 

1. We can set the datasource location property of our renderings to allow a local folder as well as the global site/data folder. 
2. We can give components and rendering variants useful names.   
3. We can add images to renderings and each variant to help content authors distinguish between components. 
4. We can label the fields to match how they are used in the layout.  I often find developers will clone the promo component and not rename the fields.  What does promo image 1 mean in a different component?  You can also add help text to a field. 
5. We can remove any renderings that aren’t used or shouldn’t be used.   
6. We can set compatible renderings so content authors can easily swap components. 
7. We can set insert options on folders so the content author can easily create the correct datasource item. 
8. We can set placeholder restrictions so components can appear in specific regions of the site. 
9. We can organize the available renderings into logical groupings in the toolbox.   
10. We can train the content authors on Sitecore itself as well as the components we build.  That only benefits the people that are working on the project currently.  We can leave component documentation.  But it often feels like a thing that will never get used and easily becomes outdated, so we don’t do it. Imagine a new group of people get hired to manage the site and they didn’t get proper training and don’t have documentation. Any problems the previous team was trained to workaround becomes frustrations for the new team. 
11. We can enable version history so content authors can track and audit changes to content. 

 These are things we all know we should do.  But these things are the easiest to skip when the deadlines are tight, the sprint is ending, and the client wants to close stories.  Maybe we should add these things to the acceptance criteria so they don’t get skipped.  Maybe we should estimate our work items to include time for these additional items. Maybe we should educate our clients on the value of doing things right. Maybe we should be a advocates to create good user experiences for our content authors as well as the end users of the website. 

If you aren’t happy with Sitecore, reach and let our team of Sitecore experts help you fall in **** with your CMS experience!