Keeping Your Sitecore Tree Organized

There's one big thing that should be on everyone's mind when working with a lot of content.  That big thing is organization of the Sitecore content tree.  With a single site solution, organization can be a little less serious.  But, once you start to deal with a multi-site solution, organization is key.  There are so many different ways for a content tree to go from being very cleanly organized to being one of the most confusing things to try and navigate.  Admittedly, I like my content tree like how I have my folders on my computer, very organized.  That way, when you need to find something quickly, it is very easy.  If it's disorganized, then it ends up being a longer process to find the item.  Which, multiplied by however many components you have on a page, could really affect how quickly you can create a site.  So, when I see a Sitecore tree that seems to have items spread out all over the place, I want nothing more than to help the client clean it up and give them the tools to keep it clean.[caption id="attachment_4256" align="alignleft" width="135"] Component Tree 1[/caption]Let's take a look at this screenshot.  In this multi-site solution, we have created components (or modules) to be added separately to the page allowing the content editor to essentially be able to build out a webpage from a blank slate.  So, due to the number of components that will be created, it is important to keep the components folder organized in order to quickly find the datasource you're looking for.  As a developer, when setting up a components folder, one of the easiest, but more restrictive, ways is to create folders yourself and only allow the content editor to insert that type of component in that folder (eg. Creating a Rich Text folder and only allow a Rich Text component to be inserted below it).  This isn't the way I wanted to implement this organization strategy since I didn't exactly know if the client wanted them to be organized by site, by component type, by both, etc.  This way also doesn't easily lend itself to growth since it's more restrictive for the content editor.  So, a more flexible way to implement this is to create a new folder template and give all your components as an insert option to this folder.  But, the key step here is to also add the same folder template as an insert option as well.  This will allow the content editor to make folders as they please and organize the Sitecore tree to how it'll make sense to them.[caption id="attachment_4274" align="alignright" width="300"] Component Folder Insert Options[/caption]Now, these were all ways as a developer to help the content editor.  But, a content editor should utilize these tools that the developer has implemented.  If a developer hasn't implemented a good way to organize the Sitecore tree, it is absolutely worth asking.  This will only help out with confusion in similarly named components, identically named components that are different templates, etc (as mentioned in Keeping Item and Field Names Unique).  As a content editor, it is also worth thinking about how you want your data structured in Sitecore before you start building out your content.  This way, you could build out your folder structure logically before adding any sort of content.  If you don't want the ability to create folders of your own, but want the restriction of only being able to add a specific component(s) under a certain folder, work with your developer and implement it together.  This way, you'll have a way to organize your data that you'll be happy with.  Personally, I'm a fan of giving the content editor the ability to structure their data as they please.  This allows the solution to easily expand if additional sites are added.  This also gives the ability for the content editor to change their mind about how the tree is structured.  Let's say the content editor just wanted all the components to be grouped together regardless of site.  Well, after the content editor starts to get hundreds of components, that organization process may not be sustainable anymore.  Instead of needing to go to the developer and paying to have an additional ability to change how the content tree is organized, that ability is already there and the content author can alter that item structure without any negative effects to the site.[caption id="attachment_4277" align="aligncenter" width="235"] Component Tree 2[/caption]In the end, as a developer, the most important thing is to deliver a solution that the client is happy with.  Knowing full well that there will be some complex data that will need to be made easier for a content editor to work with, organization is key.  As you can see in the "Component Tree 2" screenshot, I have organized the components from the "Component Tree 1" screenshot into easier to understand folders by using the same insert options as shown in the "Component Folder Insert Options" screenshot.  If there are even more components, and there still are too many items under each folder, you can easily add another level of the site that they're created for.  But, for this situation, just doing the one level is enough.  It is all dependent on how much content is going to be going into each site and how easily it is to understand where to find those items.