Creating an Object-Oriented CMS with Webflow

When you work with the “chief evangelist for Object-Oriented UX,” you and your work are held to a certain standard. OOUX is a powerful design tool, but it’s a new way of design thinking, so we’ve got a responsibility to show the world what it can do. Our house has to be in order. So the example I’ll be using to illustrate the OOUX of creating a CMS in Webflow is my first, main, and on-going website project — and one that has to be, on principle, a shining example of OOUX. (No pressure.) OOUX.com.

Once you’ve distilled the main objects in your system, you can start to visualize your CMS. In Webflow, those objects will equate to your CMS collections. And the relationships between those objects will result in your “referenced collections” (or in OOUX-speak, “nested objects”).

But before we go into how to connect your CMS collections in Webflow (and how not to do it), let’s take a brief trip down memory lane.

(As I walk you through this story of progress, growth, and headache, I’ll use Sophia’s convention of capitalizing the names of CMS collections [objects].)

The original, “Phase 1,” manifestation of OOUX.com was built by Sophia sometime early in 2020, and consisted of just two CMS collections: STRATEGISTS and TESTIMONIALS.

A STRATEGIST has 1-many TESTIMONIALs. A TESTIMONIAL has 1 STRATEGIST.

This is a slide with actual screenshots of the original OOUX.com. It was just a place to post the pictures, names, and TESTIMONIALS of those who had gone through the OOUX Masterclass Certification. A place to provide STRATEGISTS with something to show off their accomplishment (and official certificate!) and for us to show off all the wonderful things they were saying about the program.

(Side note: Earlier this year, our STRATEGIST collection was converted to PERSON because we were featuring more and more supporters-but-not-strategists on the site, like Brad Frost, Scott Kubie, and Marsha Haverty). For now, I’ll refer to them as STRATEGISTS to keep us in the moment. How we made this change and the lessons that came with that transition, is another story for another day.)

It wasn’t until Spring 2020 that I came on board with zero Webflow experience and just the tiny amount of C programming language I needed to get through engineering school. One of my first jobs on OOUX.com was to add our third CMS collection to the system: RESOURCE.

Over the years, Sophia had amassed a decent little library of original articles, podcasts, and talks, plus a few of the newly-minted Certified OOUX Strategists were creating OOUXey materials as well. We needed a place to exhibit all that valuable content. So the RESOURCE object/collection was born (read “collection” and “object” interchangeably as we talk about OOUX and Webflow).

Those three collections were easy to create. Webflow makes it easy. The hard part is deciding how to connect these objects to each other. Now the thinking cap comes on. Take RESOURCES and STRATEGISTS. Like 99 percent of relationships, the relationship between a RESOURCE and a STRATEGIST goes two ways. In the parlance of OOUX, RESOURCE and STRATEGIST are mutually nested objects. In Webflow, this relationship will manifest by creating a “referenced collection” connection.

A STRATEGIST would have 0-many RESOURCES and a RESOURCE would have 1 STRATEGIST author with it (until later…now a RESOURCE has 1-many authors…and some are certified and some are not…another story for another day!)

The connection goes both ways. STRATEGIST and RESOURCE are mutually nested objects. A RESOURCE has 1 STRATEGIST. A STRATEGIST has 0-many RESOURCE(S). Later the relationship between RESOURCE and STRATEGIST would become 1-many, but that’s another story I will cover later.

But in the Webflow CMS, we don’t have to build the relationship both ways for that two-way relationship to be reflected on our screens. Yes, we want the author (STRATEGIST) of the RESOURCE to show up on the Resource Card and Detail Page. And over on the Strategist Detail Page we want all of their RESOURCES to show up. But in the Webflow CMS, and this goes for most CMSs, we don’t want to create redundant references (let us know if you use a CMS that requires this).

Should RESOURCE collection settings include a referenced collection for the STRATEGIST author?

Or, Should a STRATEGIST collection settings include a referenced collection for all the RESOURCES authored?

One thing is for sure: we don’t want both of these connections..🤯

Every time we add a RESOURCE, we don’t want to have to tag the author and then navigate to the STRATEGIST and tag the RESOURCE. This would be a ton of extra work from a content creation standpoint.

So what would make the most sense, connection-wise?

Should RESOURCE collection settings include a referenced collection for the STRATEGIST author?

-OR-

Should STRATEGIST collection settings include a referenced collection for all the RESOURCES authored?

For this scenario, the answer seems pretty straightforward. Because we will be creating RESOURCE(S) way more often than STRATEGIST(S), it makes more sense for a content manager (me) to add a RESOURCE and tag the author there, rather than add a RESOURCE and then navigate to the STRATEGIST author and add the new RESOURCE to it. But sometimes, the question of “which way to build the connection” is not as clear.

To illustrate a stickier situation, let’s skip forward about 16 months in the development of OOUX.com and look at another CMS collection that came into the mix just a few weeks ago: TOPIC(S).

SIDE NOTE: in the interest of full disclosure, the actual collection is called RESOURCE COLLECTION, but for the sake of your sanity and mine, I’ve changed it to TOPIC(S) in this article so that we don’t all go cross-eyed trying to keep track of a Webflow collection called RESOURCE COLLECTION.

Once we had amassed a library of over 100 RESOURCE(S) on OOUX.com, Sophia got a hair to start organizing them into TOPIC(S). And after some conversations with OOUXer and SEO expert Nicole Hess, we both got pretty excited about spinning up lists of RESOURCES that centered around popular TOPICS like Content Strategy, Design Systems, and XR. Boom! A new CMS collection was born.

So I jolly-romped into Webflow and made it happen. A TOPIC would have a text field for title, a URL slug, an image field for an icon, some body text, an order number (for sorting the TOPICS), and of course, a referenced collection for all its RESOURCES.

Right?!

Not right.

That’s where I made my mistake.

I didn’t think through the connection I made between the TOPIC and RESOURCE collections.

One question I should have asked myself is, what do we create more of? We create or add new RESOURCES every week. But after the initial launch of our handful of TOPIC(S), A new TOPIC gets created once in a blue moon. So if I’m going to be creating and configuring new RESOURCE instances every week, why would I put the mechanism to connect a RESOURCE to a TOPIC, over on the TOPIC? That would mean I’d have to create the RESOURCE, then click out of the RESOURCE, click into the TOPIC, and add the RESOURCE there.

Here’s a video illustrating the point.

Still with me?

This is where the Relationship Requirements round of ORCA can save us rework down the road in Webflow (or any CMS we are designing). We can think through the direction of connection (mechanics and cardinality) before we start building anything.

As of this moment, my RESOURCE and TOPIC collections are still built incorrectly and I’m staring down the barrel of an hour of tedious rework copying down all the resources and which collections they belong to, creating a new multi-select field in the TOPIC, and then transferring everything over.

If the issue was only a content management one, I might not bother to make the change. But in Webflow, how you build the connection also affects the UX. I realized that as RESOURCES are added to our system and then assigned to a TOPIC, the newest RESOURCE should show up at the top of the list (most recent).

Imagine a use case where you, in your role as a Content Strategist perhaps, have bookmarked our OOUX and Content Topic. Every now and then, you check back to the TOPIC page for the new resources we’ve published that month. But we aren’t showing the most recent at the top, so you never see anything new there. You’re a busy content strategist. You’re coming to our site in a spare moment. You don’t have time to scroll through a long list of content to puzzle out what you haven’t already seen. So you shrug and move on.

We want to avoid this failure use case. Currently, our TOPIC-RESOURCE relationship is set up exactly how we don’t want it to be — with RESOURCES as a referenced collection on the TOPIC, instead of vice-versa. In Webflow, this means the RESOURCES are listed in the order they are added to the multi-select field. So we have no capability for sorting the RESOURCES listed on a TOPIC page!

I had tunnel vision when I set this up. I was thinking about this particular TOPIC instance: Getting Started In OOUX. I knew I wanted to list the RESOURCE(S) in this collection in a particular order. I didn’t think about other sort/filter options or the collection’s larger place in our system.

In all two-way relationships, you should think about which referenced collection will need dynamic sorting the most.

Is it more important to sort the TOPICS nested on a RESOURCE detail page? Or is it more important to be able to add logic to sort the RESOURCES nested on the TOPIC detail? Because most RESOURCES will be a part of only 1 (if any) TOPICS, it’s definitely more important to sort our list of nested resources. With the current setup we aren’t able to take advantage of that functionality!

Hopefully this was interesting and useful. Have you run into this problem before — in Webflow or any CMS? Just hit reply and let me know.

I’ve got more insights into how OOUX can be used to build sites on Webflow, which I plan to share in upcoming articles, so stay tuned for why a RESOURCE came to have 1 to many STRATEGIST(S) and what problems this caused in Webflow.