Published on February 17, 2015
Recently we've seen some debate about content trees and the role they play in the modern CMS market. Some have pointed out our supposed lack of content trees, and we thought we could join the conversation. We think it's a reasonable starting point to discuss classification strategies in general: it's not about "can you create a content tree", but rather why would you want to do so.
We'll start with the claim that "Contentful for the most part relies on flat structures with tagging", as Lukas Smith puts it. That's not entirely true: Contentful indeed enables organizing content in trees, although the approach is somewhat non-conventional. The content tree is traditionally designed from top to bottom, and has a very familiar visual representation. In Contentful you wouldn't have all that, but there is a nice alternative: hello, references.
Create a content type and declare it a category: Sports. Open several articles and link them to the Sports category. Well done! That's a content tree for you.
This approach has certain flexibility implications: for instance, there would be no need to manually move documents when one wants to change their category. Also, it's perfectly fine to have more than one category.
That may sound weird, but why have the content locked in one of the branches of your tree, when it makes sense that it should belong to two different branches at the same time? Revisiting the example of an article about the economics of sport: to make things simpler, it's best to keep the article in both categories, which is enabled by referencing.
Contentful enables using content fields as metadata, which means that it's possible to use a mix of references and tags. Say you want to have up to three levels of linked entries, which would correspond to two levels of folders in a tree structure. And one more thing: the third level should be subdivided in subcategories. This is what you would use tags for.
An example of that would be Sports / Tennis / Australian Open 2015
division. To identify each player in the tournament, apply tags like Roger Federer
– creating a subfolder for each player would be unreasonable.
Another benefit is that with Federer
stored as a tag it's possible to find everything related to Roger Federer across other categories – Sports, Celebrity Gossip, Economics and so forth. The querying capabilities of Contentful API let users query and get all the branches of the trees, mix references with tags and end up with a structured tree of the content (JSON with included JSON).
If you organize the content in a way that a parent entry contains the common elements of all its sub-entries (think categories) and include the referenced (linked) entry, you'll get all the data from both entries, which is a perfectly valid simulation of inheritance.
A good example of this is the article of a Sports category. When you pull the article entry, you can include the data within the same request of the category as being part of the API response and therefore as part of the article. Here is the request:
The JSON corresponding to this request consists of two parts. First, the entry itself:
And then the included category with the category description at the bottom:
Another common classification strategy is facets – multiple filters designed to simplify finding the relevant content slices. Think of an online clothing store and parameters such as brand, color, size and price. And the sole reason facets are mentioned in this paragraph is because they are supported by Contentful as well.
It's perfectly simple. Split all the structured data about the content entry across fields: size becomes one field and color is another. Having everything organized in this manner, performing a filtered search becomes a matter of connecting the given parameters and putting them into one API request.
Seeing the different ways Contentful offers in regards to organizing content leads to the next big question: which classification strategy is right for me? Tags, or maybe a tree? Or both?
Problem is, there is no one right single answer to this. A content model can't be considered good or bad on its own. Rather, the quality of a content model depends on how well it handles the specific use cases it's been designed for.
We are not willing to limit our users to one thing or another. We strongly believe that the users know what they're doing and that their knowledge and experience help them make the right choice when it comes to a "tree vs. tags" type of debate. Each pattern is right for certain circumstances, and each can be promptly implemented with Contentful. Flexibility is at the core of Contentful design.
Content trees are fine for some cases – for instance, evergreen content such as web pages that do not change much or a support knowledge base. Other classification strategies work best for different content types. You should learn all the patterns and make the right choice based on the project requirements. Contentful aspires to be a fit regardless of the choice.
Subscribe for updates
Build better digital experiences with Contentful updates direct to your inbox.