Defining Modular vs. Static Templates

March 4, 2021

When we discuss websites with clients, we commonly receive requests for builds that are something like a “4 template site, with templates for the homepage, about, blog, and contact.” It’s quite possible that each of “homepage, about, blog and contact” are individual templates when thinking about the website from a static perspective but it’s generally preferable to consider these 4 pieces of content identified are pages, not necessarily templates. By definition, a page is the content that appears on the site while a template is the structure that holds that content. If we can change the way we think about these pages to use a modular approach instead of a static template, there will likely be some common elements across all of them. This mindset provides opportunities for reusing modules to build the pages more dynamically.

Another topic that comes up with these template-based projects is that the site owner wants something designed for ‘Template A’ to also show up on ‘Template B’ down the road. From the owner’s perspective, this makes sense. Why can’t I have something that exists on my site show up on other pages? These are the kinds of limitations that a static template approach creates. While it may be easier to estimate upfront costs for static templates or create a content plan around them, you are actually doing a disservice to your client by painting them into a corner. Depending on who’s entering the content, the client may not be aware of this issue until a few weeks after launch when they want to move the content around.

This is where the modular approach comes in. Using modules allows you to have a library of modules/sections that are available to add content on any page in a flexible manner. Depending on the platform you develop with, there will be varying levels of flexibility available.

 

Static Templates

Wireframe outline: Static Template DefinitionAn example of a static template can be found on the right. You have your common global elements like the header and footer with the template body content between them. The static template body has the page elements designed to appear in a specific order. When it comes to content entry for these kinds of templates, you’ll commonly find all the fields that map to each section of the page as seen on the front-end. This creates consistency across common content types on the site, which can sometimes be desired but it also limits your flexibility.

A site will usually have multiple different templates that you can use to create your pages. Each template will be designed to serve a specific purpose and will contain various page sections to reach that goal. The issue with this building approach is at the time of designing your site you may have one set of goals, but those can change quickly as new business requirements appear. If you need to create a new page but none of your templates allow you to solve your new challenge, you are forced to reach back out to your developer to create a new template for that new specific goal.

This is where the rigidity of templates becomes a vicious cycle. Each new problem your site needs to solve will require a new template of some sort, which means you’ll also need to request development help to solve them. Eventually, over time, you’ll have so many templates that the site also becomes difficult to use.

 

Dynamic Modules

Wireframe outline: Dynamic Module DefinitionModules (according to this approach) are most easily explained as reusable design blocks or sections of a page. Looking at the same page from the template example under a new lens of modules, we can see how it gets broken down. Instead of declaring the elements of the page in a specific order and locking them into a template, we can provide more flexible modules for the site owners to work with and allow them to create a similar result. The big difference here is that if they would like to rearrange, remove, or add a module from the page it wouldn’t require developer assistance. It would be as simple as reordering, removing, or adding a given module on the site admin.
Disclaimer: The amount of flexibility will depend on your content management system (CMS).

This also creates a much more future proof version of the site. As mentioned with templates, new business requirements are going to arise. When these do happen, many times all you really need is to pull a section that’s in use on another page. With a modular approach, you can make that happen as all pages have all the modules available to them. Other times, you need one or two new modules to solve the given problem. Creating individual modules for a page vs creating a whole new template will require less development time, saving you budget, and will get your new page published faster.

Depending on your Content Management System (CMS), you may have a few more tricks available. One of the few benefits of a more strict template approach is that you ensure a specific content type will always have the content you need. In WordPress, their modular system called Gutenberg allows you to define default modules for a content type and even lock them into the page so authors can’t rearrange or remove the sections. This gives you the best of both worlds, flexibility on the content types that you want and structure on the ones you don’t.

When it comes to your next website build, we would strongly recommend thinking about your site with a module-based approach in mind. It will set all parties up for success both now and in the future. Providing the flexibility the site owners need to make any content they’d like with all the pieces that the designers and developers worked so hard to create.

Stay in Touch!

Subscribe to our newsletter.

Solutions Architecture

browse through our blog articles

Blog Archive