The title of this article is deceptively simple. On first glance, the management of lists in Drupal and other CMSs appears to be a trivial matter. Drupal offers a range of tools such as content types, vocabularies and relationships to manage lists. The powerful Views module makes it simple to generate lists using a no-code approach which is readily within the grasp of novice site builders. The creation of lists is therefore something which is trivial to do and therefore probably doesn’t need much further thought.
However, some nuance is required when various tradeoffs are considered:
- complexity vs. simplicity
- editor vs. site builder control
- rigidity vs. flexibility
- automation vs. curation
- specifics vs. generality
The content modelling process must weigh up these priorities. Let's look at some different approaches and the various pros and cons before looking at a couple of examples of how this has been implemented in the wild.
Different approaches
Starting point
We will start with a simple site which has three content types:
- Pages: Hold content and are used to build the site structure.
- Articles: Time-based content
- Resources: Evergreen content with no time aspect.
This content model is for very simple sites with no need for filtering, aggregation or facetting.
Approach
- Top level listing pages with no filtering
Typical sitemap
- /articles, Page with a custom view
- /resources, Page with a custom view
- /search, Page with a custom view and no facets
Use when
- Site is very simple
Advantages
- Lightweight
Disadvantages
- No filtering
Conclusion
- A starting point for simple sites.
Fragmented categorisation (taxonomy)
The first approach, and one which is very common for many sites, is to add category vocabularies for simple filtering. It is called “fragmented” because it uses different categories for each type.
View the fragmented categorisation schema
Approach
- Taxonomy terms are used to filter lists.
- Site builder manually creates Views for each term and embeds on specific pages.
Typical sitemap
- /articles, Page with a custom view, filter by the article categories
- /resources, Page with a custom view, filter by the resource categories
- /search, Page with a custom view and no facets
Use when
- The content types really do have separate categories.
- Content only needs to be filtered, not aggregated.
- Users will never need to visit the category pages.
Advantages
- Lightweight and specific.
Disadvantages
- There is no unified categorisation across the site for faceting and filtering.
- Site builder driven: Laborious and brittle.
Conclusion
- Often an easy, initial design decision which can lead to fragmentation.
Unified categorisation (taxonomy)
The next approach takes a unified approach to categorisation by sharing a common vocabulary across the content types.
View the unified categorisation schema
Approach
- Taxonomy terms are used to filter lists.
- Site builder manually creates Views for each term and embeds on specific pages.
Typical sitemap
- /articles, Page with a custom view, filter by categories.
- /resources, Page with a custom view, filter by by categories.
- /search, Page with a custom view and a category facet.
Use when
- The content types can be unified by a single categorisation
- Content only needs to be filtered, not aggregated.
- Users will never need to visit the category pages.
Advantages
- Lightweight and general
Disadvantages
- Categories may be considering first class objects in the future which need rich content, a URL and users will want to visit them.
- Site builder driven: Laborious and brittle.
Conclusion
- A big win for generality and functionality of the site.
- May diminish the power of the category by not allowing users to visit the page directly.
- Potentially an SEO loss because the category will not be indexed in search engines.
Unified categorisation (content type)
This next variant makes the category a first class object, a content type. It is expected that users will want to visit the category nodes and see aggregated content there.
View the unified categorisation schema with nodes
Approach
- Nodes are used to filter lists.
- Site builder manually creates Views for each Category and embeds in the full content view mode for the category.
Typical sitemap
- /articles, Page with a custom view, filter by categories
- /resources, Page with a custom view, filter by categories
- /category-x, Category with a listing of relevant articles and resources
- /search, Page with a custom view and a category facet
Use when
- The content types can be unified by a single categorisation
- Content needs to be filtered and aggregated
- The categories are strong enough to stand on their own and users will want to visit them.
Advantages
- Categorisation is a first class concept and general.
- Site builder efforts are scalable as the single View applies to all categories with no extra effort.
Disadvantages
- A category content type may be considered too heavy if it is just for filtering.
Conclusion
- A strong contender for being the default choice for categorising content.
Sub typing
Subtyping vocabularies or content types can be used to classify content into a single subtype. This adds another dimension to the content and is helpful for creating automatic listing pages for each subtype.
Approach
- Nodes are used to filter lists, i.e. they are used in the same way vocabularies usual are, in this case they are nodes.
- The site builder creates a View for each Subtype and embeds in the full content view mode for the subtype.
Typical sitemap
- /articles, Page with a custom view, filter by categories
- /resources, Page with a custom view, filter by categories
- /category-x, Category with a listing of relevant articles and resources
- /article-type-y, Article Type with listings of relevant articles
- /resource-type-z, Resource Type with listings of relevant resources
- /search, Page with a custom view and a category facet
Use when
- There are many subtypes for the content
- Content needs to be filtered and aggregated
- The subtypes are strong enough to stand on their own and users will want to visit them.
Advantages
- Complex sites will benefit from the structure
- Editors get listing pages for “free” for each of the subtypes.
- The site builder's efforts are scalable as the single View applies to all categories with no extra effort.
Disadvantages
- Runs the risk of being too heavy if the site doesn’t need it.
Conclusion
- Can be a win for complex sites.
- Information architects may struggle to work out where to put the subtypes in the sitemap.
- Can be difficult to conceptually understand.
- May be overkill on simple sites.
Is listing
The concept of “listing” is a flexible way to assign Pages to being special listing pages. For the computer scientists, you can think of it as a Page having a trait or interface of being a listing. This allows Pages to be uplifted as needed and then content can be assigned to them.
Approach
- Pages have a field_is_listing boolean to indicate whether they can operate as a list.
- Articles and Resources have a field_appears_on entity reference field which can contain any Page which is considered a Listing.
- The site builder creates a “Content list” View which is placed on the Page - it will show all content which has been assigned to it via field_appears_on
Typical sitemap
- /articles, Page with a custom view, filter by categories
- /resources, Page with a custom view, filter by by categories
- /category-x, Category with listings of relevant articles and resources
- /listing-page-a, Page (which is listing enabled) with listings of relevant articles and resources
- /search, Page with a custom view and a category facet
Use when
- The categories are strongly controlled and editors need more flexibility.
- Content needs to be surfaced in an ad hoc manner across the site.
- An uncontrolled vocabulary such as “tag” is too weak
- The pages which you want to surface content on are important in their own right.
Advantages
- Flexibility
- Lightweight
- Editor driven
Disadvantages
- May be considered to offer editors too much control.
- An added level of complexity for flexibility which may not be needed.
Conclusion
- A smart way of adding a lot of flexibility and editor freedom.
- Can expand to handle new requirements.
- Doesn’t threaten strongly controlled vocabularies.
- Good for systems which value flexibility over rigidity.
The whole 'enchilada'
And sometimes you need everything to model your content. This final approach combines categorisation, subtyping and listings.
View the schema with everything
Approach
- Combination of a few of the above approaches
Typical sitemap
- /articles, Page with a custom view, filter by categories
- /resources, Page with a custom view, filter by categories
- /category-x, Category with listings of relevant articles and resources
- /article-type-y, Article Type with listings of relevant articles
- /resource-type-z, Resource Type with listings of relevant resources
- /listing-page-a, Page (which is listing enabled) with listings of relevant articles and resources
- /search, Page with a custom view and a category facet
Use when
- The categories are strongly controlled and editors need more flexibility.
- Content needs to be surfaced in an ad hoc manner across the site.
- An uncontrolled vocabulary such as “tag” is too weak
- The pages which you want to surface content on are important in their own right.
- Subtyping is needed to add structure.
Advantages
- Ultimate structure and flexibility
Disadvantages
- The most complex
Conclusion
- Suitable for large corpuses with many types and aggregation points.
It all depends…
In the section above, the advantages of unified categorisation and the use of content types over vocabulary should be clear. There are easy wins for generality and scalability.
The case is not so clear for the use of subtyping content types. They can be very useful on complex sites, however, in general they may be too heavy for simpler sites.
The concept of “listing” pages is a clever one which can lead to big flexibility wins for editors with a very minor addition to content model complexity.
How is this handled out in the wild?
Each site will have its own requirements and should be built in a way which best suits its individual needs. Looking at individual sites will therefore have little illustrative power. It is, however, worth looking at some general purpose Drupal distributions to see how they handle the above considerations.
We will look at three general purpose codebases.
Acquia CMS
The Acquia CMS content model takes a “Unified categorisation (taxonomy)” approach for categories. It also uses vocabularies for subtyping.
The diagram above is not actually the schema for Acquia CMS. This has been adapted to reflect the approach using the content types used in this article. View an adaption of the Acquia CMS schema
This is a sensible approach as the categorisation is general and can work well across the site.
The logic here is to introduce categorisation and typing for the organisation of content. However, Acquia CMS stops short of extending the categories or subtypes to being first class objects, being at the level of taxonomy rather than content types. The approach is therefore centred on filtering lists at the top level, rather than aggregating content into a node which users can visit.
Interestingly, the concept of tags is also included. Tags are a flexible and lightweight way to add flexibility for editors.
Overall, this is a sensible approach, as the categorisation is general and can work well across the site. Users have ample opportunity to filter as needed and the content model stays lightweight and focussed on the main content types.
The potential downside is that the categories, tags and subtypes cannot be visited by users, unless a site builder builds out pages for those.
Convivial CMS
Convivial CMS, a starter site developed at Morpht, works in a similar domain to Acquia CMS in that it provides a small set of useful content types for common use cases. A slightly different approach has been taken.
NB: Not actually the schema for Convivial CMS. This has been adapted to reflect the approach using the content types used in this article.
View an adaption of the Convivial CMS schema
Categories (topics) are general and work across all content types, however, they are modelled as a content type rather than a vocabulary. This allows users to visit a category page.
There are no subtyping vocabularies or content types. The decision to leave these out was taken for simplicity's sake. Not all sites need these. If they need to be added then they can be. If they were to be added, it is likely they would also be created as a content type.
There is no “tag” vocabulary. In its place we have the concept of “listing” flag for Pages. This allows pages to be uplifted to be a list if required. This ensures that we only need one object to represent a concept. As Pages are fully featured (with components, etc), it makes it possible for editors to build out rich experience for users rather than relaying a lightweight tag term.
Conclusions
The humble list is not so humble. This article has attempted to cover many of the aspects we take into consideration when designing and architecting our Drupal sites.
I have made a strong case for
- using cross-cutting generalising categorisation,
- using first class content types over vocabularies
- using subtypes where extra structure is required
- using “listing” flags to provide flexibility.
On balance, I believe these guidelines help promote the aims of
- simplicity
- editor control
- flexibility
- generalisation
Each site is different and where you draw the line will depend on the individual needs of the site.
I hope this has been of benefit to you and maybe added one or two tools to your Drupal toolkit.
