Don’t Fight The Framework – Is it wrong to consider Sitecore content as ‘Pages’?

A recent comment by Martin Davies to this short post inspired me to take a subject that is always going to be a marmite one with us as Sitecore developers. So I will start by saying, firstly – this is not a dig at Martin in any way, I have met many developers that share the view made by his comment and that, this is very much subjective and a presentation of my view as a counter proposal – I personally have changed my mind a few times on this subject.

A ‘page structure’ as you Martin eludes to in his comment, is for my mind at least a collection of items which have presentation (generally making up the site map as we see it), as such (for me), it is a content structure like any other. I have seen on my travels both ‘page’ content structures with non-page items and ‘page’ content structures with items. I personally don’t feel the need to enforce a user to not put items without layout in some other place if the most logical place is potentially to keep it close to the item in question. I would say though – we as developers (and often users) like to see the world in our little silo’s and we can (if we think about it) get a happy medium. I will however qualify this further by looking at specific use cases, so lets consider some real world examples:

Free Text, Call to Actions & Carousels
Ok, so the first, and very common one would be a ‘free text’ item, these are usually items that are added ’cause we don’t want to add a specific field for 1 piece of text, so we create an item and use it as the data source on a ‘free text’ rendering. In my opinion, these (and this will be a marmite view I suspect) can live either in a ‘global’ location or beneath the page they are used, depending on whether the content will likely be re-used. This would probably also apply to the likes of carousels or call to actions.

Items like social media settings items (think twitter feed items for example) should almost always live in a more ‘global’ location.

Items For Structure
Well – when you think about it – as Nick has mentioned in his post here, Sitecore (in the words of Rocks) gets ‘grumpy’ when you start adding larger amounts of content under single folders (though I have found in reality you can usually get up to around 250 – 300 items without the users moaning). So we as developers often find ourselves creating (taking News or Events structures as an example) ‘Group’ items, such as ‘Year’ or ‘Month’ in order to split content for the user. These (in the majority of installations) are usually presentation-less content items – which is bad right? Well, no – most would argue it’s ok in this use case even if they share a hardline belief similar to that which Martin’s comment showed.

The happy medium?
Well, we have already established that (many of us) are happy to have items for structure on certain occasion, I (like some others) believe that its on the user to decide whether their content belongs globally or not, so why not…. Dun dun dun……. Mix the two and have a ‘page specific elements’ structure that a user can add beneath an item of content (side note, I personally like the blue folder icon for this – icons are important – just saying!). This is seemingly at first kinda still going against Martin’s shown ideal, but in reality – we are quickly back to our happy silo-ed existence, ’cause when we open the content tree we have a lovely little structure that shows us that a user has added some Page specific text, or a carousel, without having the (and like I said – I have changed my mind, cause I originally was happy with this) 5 – 10 additional free text / carousel / call to action items that make it harder to see the wood for the trees, especially when there are many other items. Add to this the help of the notable icon (whichever you may choose – *BUT CHOOSE THE BLUE ONE*), you can quickly as a developer or user, disregard it if its not what you are looking for.

As we are aware, the relationship between developer and user should almost always be the developer acting as an enabler for the user / end user, its on the user to know what they want from their site, how they want to present their business to their client. It’s on us as developers to make that happen. As such – I (certainly) as a developer / architect / whatever hats I have worn have learnt not to attempt to second guess what the user wants, I just want to give them a solution that allows them to be as free as they can be whilst not making my life a pain. The example above is one of many whereby I have kept adapting my idea’s (and it will no doubt continue) to allow the user to actually manage their own content without getting in my way, leaving me to do what I actually love doing and getting my hands dirty (coding amongst other things).

As with all of the things I speak of in our posts, I am not at all hard line on my views and welcome feedback (go on, I know this is a contentious one :D). As an answer to the title – in my opinion, we should detach ourselves from the idea that a Sitecore item is a ‘Page’.

7 thoughts on “Don’t Fight The Framework – Is it wrong to consider Sitecore content as ‘Pages’?

  1. Interesting post, as a golden rule i would never normally advocate putting non navigable items in the page structure. Sitecores best practice also echos this.

    Providing the page editor has been setup correctly, is there ever a need to store sitecore items hierarchically beneath the page? Surely a good implementation of Datasource template and Datasource location would negate the need to ever need to store non page items in the page structure?

    • In this instance I am still both using and advocating good set up of data source and data source template, but have found in my experience that storing EVERYTHING in a shared location usually tends to lead to structures that are heavy and complex, add to this, permissions are not quite as easily maintained at a granular level. It this model, permissions are inherited from their parent, meaning standalone free text or carousel items for example are only allowed in sections where the user has rights as opposed to the common case of a shared ‘text items’ location. There are other benefits to as regards the grouping as it is a simple task to figure out where an item is used and less likelihood that a user will modify an item that is being reused elsewhere. Like I said in the post, I believe this will be a marmite topic and great to discuss. I appreciate the time you take to comment.

  2. I totally agree with you. In fact, all of the builds that come out of our team use both the concept of “Site Components” and “Page Components”, which allow authors to decide if they want to share the datasource they are building with others, or put it in their own “little blue folder” that is immediately below the item.

    Security can then be used to prevent users who shouldn’t be allowed in the “shared sandbox” from editing there, and they can only create inside their own scope.

    I just checked our builds to see what icon we chose for the folder… it wasn’t the blue one. I should log a bug with the framework team! 😉

    • For sure !! I will be highly entertained if I ever pick up an existing build to find ‘blue folder’ sub items. I guess technically speaking we should use the term ‘Related Content’ rather than ‘Page Specific’ or ‘Page Components’ since it could eventually have its presentation removed or become another type of sub-item but that is semantics and being fussy 😀

  3. The argument to keep all the items out of the content tree can be further blurred when you consider an accordion. The item and its content are intrinsically associated together but you want to support an arbitrary number of accordion items.

    Further, you may have to support accordion items of different types where one is text, another may have an image and a quote and yet another may have an embedded carousel.

    In a single language site, this is definitely easier underneath the associated item. But for a multi-language site where the trees are merged then this isn’t necessarily a good idea.

    In my experience, most of the Sitecore editors don’t actually get Sitecore training. So their comfort with using datasources and the like comes much later and compromises are insisted upon by the client.

    Given the choice for the example above, I doubt I could give one that I wouldn’t change my mind on. Each content structure is different and my accordion component should be able to load items based on datasource and then context item children.

  4. In my experience; users “need for” and “comfort with” a page-oriented like information archtiecture like the one you describe here comes from the original Sitecore training they have received. And this is not the official training; this is often a developer giving the editor a 2 hour tour and “off you go”.

    These days, I always build a page-template-less information architecture, and my training of editor users just take on this approach from the very beginning. They get it, and can work with it just fine afterwards.

    That being said; I do believe a re-think of Sitecore’s Content Editor interface would be useful – because it does lend itself almost exclusively to a “one item at a time” approach – and provides no easy overview for users.

    How often have you found, users prefer the “child items to my page” approach and really wondered; “is it because they don’t really understand Presentation Details”? My gut feeling is, that that’s exactly what it is – never have I managed to get editor users using it. Via Content Editor, that is – Page Editor is an absolute must in any user training.

    At the end of the day though; if you end up implementing components that are irresponsive to Sitecore datasourcing, cannot be hidden in a conditional rendering condition, cannot be swapped for something else without invoking a Visual Studio and a rebuild – then it’s not Sitecore you are building. It’s a website. Those are my 2 cents – an opinion amongst many 🙂

    • A great response Mark, cheers!

      I totally agree with you on the ‘Children of my page’ issue – it is very likely a symptom of the tree style UI given by the Sitecore Content Editor – it is one that seems to plague many a WCMS. Sitecore (I hope) will address this in the future with an improved UI, as I believe it is one of the big issues to resolve in terms of getting true ‘Big Data’ into their solutions (I am not a huge fan of buckets in honesty – but that’s a whole other ball game).

      Since the first day I started developing with Sitecore (before I had any training) I realised that the presentation architecture is hugely important (see – I think the views in this post mirror your opinion of the Visual Studio rebuild attitude). That said, I have developed (in the past) ‘self discovery’ controls that look for the first matching child with a given template (carousel for example). These were always done with the ability to override using the datasource and I have always believed were kind of a compromise to bridge that gap between the users being happy in the parent > child relationship structure and the re-usability of data sources. I also think that the page editor support has only *really* been good enough in 6.6 and beyond to make it a serious alternative to the Content Editor without serious thought from the developers which has often lacked). I have to many developers living in the same heirachical content editor bubble and fail to support the Page Editor sufficiently (myself included at points).

Leave a Reply to Jason St-Cyr Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s