Maintaining Design and Function Modularity with Toolset for WordPress: Part 1

When I first began working with WordPress, Visual Composer was all the rage.

Theme developers were integrating it into their themes as a core component of their architecture left and right. The appeal in using that tool, and others like it, was pretty obvious from the perspective of those building and selling themes, but also equally attractive to those purchasing and using the themes.

The inclusion of these drag-and-drop back-end UIs suddenly meant that people with almost no design knowledge or technical skill could learn enough to maintain a website by installing a theme, importing its ready-made templates, and modifying the page structure backwards by swapping out content and moving things around.

For people with minimal knowledge of HTML and CSS these UI’s lowered the barrier for entry into website development by compensating for knowledge gaps and introducing tools that could accelerate the page build process.

Planning for Where Functionality Needs to Go

Since the debut of page builders, developers have since started to build more complex websites with WordPress. As a result, architectural planning coupled with more advanced tools has become a staple part of the build process.

One convenience that page builders can’t tackle on their own is the handling of dynamic content at scale.

For example, suppose you were creating a website to promote a service. As a part of that promotion effort, a core element of your content strategy is going to be the publishing of case studies that demonstrate all of the projects your company has completed for customers.

Technically, nothing would stop you from building a nice page layout with Visual Composer, Fusion Builder, Beaver Builder or any one of the other editors and then cloning that page over and over again swapping out content along the way until all the individual case study pages were eventually created.

While this would complete the immediate goal of having case studies with custom layouts, this approach is really only addressing the outer layer of the objective by producing static front-end pages and nothing more.

Here are some common scenarios in which the limitations of this approach could rear their ugly heads as the number of case studies increases over time:

Scenario 1: As you begin adding more case studies, you realize over time that there are distinguishable traits from one case study to another that make them unique. At the same time, there are things that they have in common that are also relevant and worth highlighting.

For example, suppose your service is a law firm that practices different types of law internationally. You might want to have several case studies for Commercial Law, but it is also of equal importance to distinguish that each of them was litigated in a different country.

The problem to overcome is: how do you create organized categorical relationships between all of your case studies?

Scenario 2: Extending scenario 1, imagine your case study portfolio grows to the point where there are so many case studies it would make more sense to have them be searchable or filterable based on certain data or facets within them.

For instance, imagine a user coming to your website to validate your law firm before calling to discuss their legal issue. How do you think they might make that assessment if they are browsing through your case studies? Most people will want to know that you’ve handled a case that has something in common with theirs. In other words, they are going to want to be able to drill down into your content to find the commonality that validates their decision to pick up the phone and call you. Therefore, it would produce a much more effective user experience with a higher conversion probability if users could have a way of narrowing down case studies based on filters that they can control and relate to (type of law, location, etc).

The problem to overcome is: how do you create case studies so that their data can feed into other valuable pieces of functionality throughout the site?

Scenario 3: As the number of case studies increases, so too does the overall page count under “Pages” in the admin. Imagine trying to sort through all of that to find the homepage or other internal page just to make a small change. Over time this would get messy to navigate and annoying to manage.

The problem to overcome is: wouldn’t it be easier to have case studies managed separately from your website’s other core website pages?

You may be thinking that this mentality seems to fit well with “case studies” only, but really, it can apply to any content type on your website. Content is a broad term, it comes in many different types and formats, and the data and attributes that are communicated through that content can be plentiful and vary greatly.

That variance is the reason why each of the scenarios above inevitably runs into a “problem to overcome.”

 In each case, a functional or design limitation arises from using a page builder that will prevent a website from being flexible when content needs to scale. More importantly, and in keeping with the title of this article, the biggest limitation is that in those scenarios there is no architectural process governing the method by which content patterns with dynamic attributes are handled in front-end design.

The solution to this is to bring in Toolset, an advanced tool that can help structure content types, and use it in conjunction with a common page builder.

As you will see in part 2 of this blog post, coming soon, drag-and-drop page builders still have their place in this solution and work alongside Toolset. Check back to read more about how these work in tangent!