Introduction to understanding content modeling abstractions

In this article, we will take a deep dive into designing effective content models that are simple, intuitive, and powerful. Before we get to a polished finished product that delivers an amazing customer experience, we have to start from the very beginning—understanding both the user and the business. As you undertake the task of designing your content model, you will have many stakeholders to juggle, each with their own varying motivations and expectations. To us, the process of designing an effective content model is both an art and a science, and in this article we will try to equip you with the tools that you need to become a content modeling artisan.

Why “design” a content model?

When it comes to delivering a great digital product, such as a website or mobile app—one of the often overlooked aspects is the experience of the developers and maintainers of the system—especially when working on a large project with a varied set of stakeholders.

Designing a simple, intuitive, and powerful content model can be the difference between a very difficult delivery and one that keeps developers engaged, excited and leaves a lasting impression on the entire delivery team, as well as the users. When we are motivated, we produce our best work, and a powerful content model that supports the imagination of the delivery team can do just that.

Great, so now that we have set the scene and established that designing a great content model is important, let’s get into the thick of this article—and one of our favorite topics in content modeling.

Example 1: What is abstraction?

You might have heard about abstraction when it comes to content modeling, but you might not know why it’s useful and how to make it work for you. It is certainly one of those things where each individual project will have its own quirks, but the contents of this article will aim to equip you with the Content Modeling Abstraction concepts and how to make sense of them all.

Let us start with a simple example to set the scene. Figure 1 illustrates a mobile app that allows users to purchase properties or find nearby rentals. We can see in the current screen that the user has selected the “Buy” option and there are three items displayed, one house and two apartments. Newcomers to content modeling have a tendency to jump straight into creating a model for the first thing that they see—a House model, an Apartment model, and so on. However, is there a simpler solution to this particular scenario?

What if our app needs to be updated in the future to support new types of items in our list? Sellers may want to post empty land for sale, parking spaces, or even a single room in a sharehouse. Is there a way that we can instead capture all of these into a simple and intuitive model?

The process of moving from a concrete type to an abstract type usually involves moving from a type that describes a physical noun instead to models that are more symbolic in nature. It can often take several leaps in our minds to jump from the starting physical object to the more generic Content Type.

When should we be using abstraction?

Now that you have had the chance to dip your toes into the world of abstraction in content modeling, you probably want to get your feet properly wet. If you want to learn about how abstraction can be used to solve complex modeling scenarios, the following examples in this article will help you. This knowledge will ultimately be platform and tool agnostic and can be applied in a variety of technical situations outside of the use case of designing a Content Model for a Headless CMS.

Now that you have had the chance to dip your toes into the world of abstraction in content modeling, you probably want to get your feet properly wet. If you want to learn about how abstraction can be used to solve complex modeling scenarios, the following examples in this article will help you. This knowledge will ultimately be platform and tool agnostic and can be applied in a variety of technical situations outside of the use case of designing a Content Model for a Headless CMS.

The following are the most common scenarios where your alarm bells should ring to alert you of an opportunity to use abstraction in your models. We will be providing a detailed example for each of these situations:

• When you are dealing with a list of items, especially when there are points of variation among them.
• When you have different types of things that have variation but ultimately go through the same process from the perspective of how the customer interacts with them in your product.
• When your natural intuition tells you that you are dealing with different “types” or “categories” of a particular thing.

As the saying goes, with great power comes great responsibility—we should be thoughtful in our decisions as to when we use abstract types versus more simple concrete types. We must be mindful of the reasons why in certain situations a concrete non-abstract type may be the better choice as well. From our experience in building and maintaining large enterprise-level sites and apps, the key to successful maintenance and longevity of a system is the simplicity of its day-to-day usage. One of the primary objectives of our content model design is for it to be simple, both from a systems perspective but also from a human’s perspective with regards to our ability to intuitively comprehend how the model works. A Headless CMS is indeed a digital tool that is consumed via an API in code, however, and more importantly, it needs to be read, collaborated on, and maintained by a human being.

We should turn to abstraction in our content models when they help our solution to be simpler and more intuitive.

Example 2: E-commerce clothing store

The following example demonstrates how one may go about thinking of modeling an e-commerce store when it comes to the items that are being sold in the store. In this particular example, let us imagine that we are a clothing store that is selling assorted items such as shirts, pants, jeans, suits, socks, etc.

Using the same line of thought from our earlier example, let us see if we can start from a concrete type that represents one of the physical objects and work our way up into a symbolic type and finally only a completely abstracted type.

Now that we have a completely abstracted “Product” Content Type, we have a cleaner and clearer model that makes it easier to think about how we would easily bring all of our other items into the model. The symbolic type of “Clothing” would have limitations when we start dealing with items such as Shoes, Belts, Sunglasses, and other assorted items such as this, which may not necessarily be classified as “Clothing”—but can easily be described as a “Product”.

These simple exercises of progressing from a physical concrete type onto a symbolic type and finally through to the abstracted type can help train your content modeling muscles. Let us examine several more examples to see if we can use this same approach for other types of applications.

Example 3: When to use a symbolic semantic type

It is common to start a content modeling exercise with the dream of having a completely semantic model, where every type is perfectly representative of the real world, and no abstraction is even necessary. In many cases, this actually a very valid objective when starting your design; abstraction for the sake of abstraction should be strongly avoided. In the following example, we are again posed with the challenge of modeling a list of items, which have a decent level of variation among them in their general nature. In this case, we avoid creating the concrete types such as Credit Card, Mortgage, Term Deposit—but instead can have a single Account type that can cater to all of these. This example is purely from a general modeling perspective; bank accounts would not be stored within a Headless CMS.

Hint

In this example, you may be tempted to introduce a type that is completely abstracted and only serves the purpose of representing the item in the list, such as a “Listing” or a “Card”—however, in this situation, this is not necessary as the symbolic Account type is able to sufficiently do the job of representing all of the different items that we need to display in the list.

Example 4: Another situation where the symbolic type is correct

In the following example, we again see a situation where the symbolic type is all that is necessary. In this case, we have a Product type that can sufficiently capture all of the specific types that we are dealing with. The interesting gotcha in this scenario is the distinction of a Product vs. a Policy. In the insurance space, a “policy” is the actual contract between the insurer and the policyholder—in our example, we are displaying the list of available insurance products for the customer to get a quote. This illustrates one of the challenges when deciding the name of your symbolic types; there may be situations where one term is more correct than another tempting term.

Hint

When you find yourself having to select between a number of different terms that seem all right at first glance:

• Refer to subject matter experts from the business for a better understanding of the terminology.
• Don’t be tricked by a term that actually refers to something that “binds” one type to another (for example, an “Order” or a “Purchase” type is what binds a “Customer” to a “Product”).

Dealing with traits that are specific to certain types

When we seek to combine multiple different types into a single symbolic type, we may get stumped by the fact that some of these types that we are dealing with may have some very specific set of traits and characteristics that only apply to them and not to the other types. This may cause some initial confusion and a reluctance to combine the types together.

Let us consider a simple example: imagine that we are dealing with our mobile app that displays listings of properties that are available to buy or rent. If we think about all of the different types of listing we are dealing with, we may have the following:

• Houses
• Apartments
• Empty Land
• Parking Spots
• Commercial Space

When we examine any of these, we will notice that they have properties that only really make sense to that type specifically. For example, the notion of “number of bedrooms” only really makes sense to the House and Apartment types but cannot be applied to Empty Land, Parking and Commercial Space. So how do we deal with capturing these differences in a combined type?

Creating Content Types to represent the traits of a specific type

One approach for dealing with traits that are specific to one of our concrete types is to create a content model that represents the traits specific to it. These traits can then be linked to your listing through a relationship, which can be named something like “details” or “traits”.

The main benefit of this approach is that you have bite-sized content models that only deal with the traits of a specific concrete type. This allows you to keep your API payloads light, only transferring across data that is necessary for a particular content item, without having to send a bunch of null values for content elements that are not relevant for your specific type.

As an example to demonstrate the above point, with this approach, if we are dealing with a house listing, then none of the other unused trait elements would come through via the API:

This second part of my Effective Content Modelling series has aimed to guide you through the decision of how to effectively abstract content types. The ability to generalize a variety of different content types into a single symbolic or completely abstracted name can be a powerful tool in your arsenal as a content modeler. Remember, though, to use this tool sparingly and only when necessary, abstraction for the sake of abstraction can quickly create an over-engineered content model that may become difficult for people to practically use on a day-to-day basis.

As designers of content models, we must carefully and actively assess if an abstraction of content types brings us closer to creating a model that is both intuitive for humans to maintain, yet powerful enough to support whatever the future looks like for your product.

As you consider content type abstractions, keep in mind the following guides:

• Ask yourself if each abstraction is truly necessary.
• Consult with your business SME to ensure that your content type naming matches their understanding, especially when dealing with symbolic and abstracted types.
• When creating content types that act as traits for concrete types, ensure that you limit the usable content types for that relationship. This will greatly help content creators when entering content items.