Planning for Templates and Modules
Very often we get projects that estimate the hours it takes to code a number of templates. This approach, while fine for very detailed designs, does set up the project to be very limited on what content can happen where. The owners of these projects may be surprised to know that you can just add designed components from one page and have them magically appear on another page without a further conversation.
This is where modular design comes in. This allows you to have a library of components/modules that are available to add in content on any page.
Templates are basically things that are consistent in some fashion across the site. Header and footer designs are part of the template, but so it the structure of what lies between them.
They also typically include what many consider “placeholders” for where reusable content components can appear in. An example of some templates would be:
- Full width
They may also include pages that do not, and never will share content with other pages. An example of such would be an events/calendar page. There are heavy functionality pieces involved that would not be used design wise on other pages.
Modules (according to this approach) are most easily explained as reusable design blocks.
Modules that create layouts: The first kind of module will be more like the building blocks used to create a page. Some examples of these include:
- Hero Image/Slider
- Content Grids
- Call to Action
Modules that create content: A second kind of module would be more of a content module. These occur on things like a blog template because the author wants to alternate between various content options like:
Modules are able to have variants. It’s encourages to have each module have a default design, but they can change their look based on:
- A module type
A media module can look different if it’s an image vs. a video
- set variables on the module
A block module can look different if a header is set or not
- the template the modules appears on
A sidebar template would have a narrow variant for all the modules due to less horizontal space
When templates go rogue, and have little/no customized look between them, the module approach is harder to accomplish. In this case, you may need change orders to get certain module functionality on those pages.
Combining this knowledge for templates, modules, and module variants can create a web framework for your projects that is a lot more customizable and future proof