How to structure your content

Introduction

Goal

Structure your content using best practices in order to optimize performance, maintainability and usability.

Background

The choices you make when designing your content structure can have a significant impact on the systems performance, maintainability and usability. Once the system is in use, it can be very hard to change the content structure. This document describes some best practices for modeling and structuring your content.

Content model

A common pitfall for content modeling using hierarchical structures is that you have implicit information about the nodes (documents) stored in the containing folders.

Try to stick to this really simple rule of thumb:

👍

Store meta data as properties on the document.

This also implies that properties that you want to use to, for example, sort on, cannot be properties that are part of a child node (e.g. a field group) of your document. These properties must be stored directly on the document node itself.

Avoid creating a content structure where the folder contains metadata of the documents it contains. For example, if you want to create a content model with documents about a product (Bloomreach Experience Manager) of a company (Bloomreach), one possible structure is as follows:

❗️

• Bloomreach (folder)
  • Bloomreach Experience Manager (product)

If you model your content as shown above, you will end up writing mostly inefficient and hard to maintain queries in your delivery components.

Instead, try creating the model like this:

👍

• Products (folder)
• Bloomreach Experience Manager (company = Bloomreach )

In this case, the document property company stores the information about the document, thereby making it independent of the folder structure.

If you want access control based on folders (e.g. restrict document about Bloomreach products to Bloomreach employees only), you may want to model it as follows:

• Products (folder)
  • Bloomreach (folder)
    • Bloomreach Experience Manager (company = Bloomreach)

But in any case, try to keep the company property. Adhering to these simple rules will result in a much cleaner frontend code.

Number of items in a folder

The number of items (documents, subfolders) in a single folder can affect performance. In general, the more items in a folder, the more time it costs to retrieve the contents of the folder (e.g. to display them in the folder listing in the Content app). Apart from the negative impact on performance, this can also cause a less than optimal user experience as users have to scroll through endless lists of documents to find the one they are looking for.

As a general rule of thumb:

👍

Keep the number of items (documents, subfolders) per folder under 100.

The easiest way to achieve this is by using a hierarchical folder structure, for example storing news articles not just in a folder "News", but additionally in subfolders reflecting the year and month:

News (folder)

• 2015 (folder)
  • 12 (folder)
    • Boxing Day Sale (news article)
    • New Year's Eve Special (news article)
  • 11 (folder)
    • Thanksgiving (news article)

This way you never have more than 12-month folders per year, and you're good for a century of year folders. If you publish more than 100 news articles per month you could create subfolders for days of the month as well.

👍

Use folder hierarchy to keep the number of items per folder low.