Blog

Engineering Modular Systems

Tags: code, css, dev, js, maintainable, modular, module, php, scalable, template, wordpress.

March 18, 2014 by

Developers are naturally aware of wasteful code, whether it’s writing the same thing many times over with only subtle differences or creating entirely new templates for a minor change in the order of page elements. I start every new project with a determined mindset of “I’m going to write the cleanest code I’ve ever written,” but even with the best intentions, I often find myself straying back to the aforementioned development sins. The culprit is nearly always a lack of modularity.

The Virtues of a System of Parts

I can best describe modularity as a system of interchangeable, reusable parts – the key words being “system” and “parts” (or modules). Many of the greatest products, machines and innovations are modular – ranging from Lego to the International Space Station. Modular products and machines are known for customisability, versatility, durability and long lastingness.

blog_iss_module
The Russian “Mini Research Module 2” docks with the International Space Station. The ISS was designed as a modular structure to ensure the longest possible life-span.

As developers, we should also aim for our code to be long-lasting and customisable, and importantly – economic. Economic code comes from reusability which translates to less code written per project. Durable code comes from independently functioning parts that can be added or removed without impairing the overall system, which translates to maintainability and extensibility.

Modularity is by no means a new concept in the world of programming. In his book Eloquent JavaScript, Marijn Haverbeke writes:

“In small programs, organisation rarely becomes a problem. As a program grows, however, it can reach a size where its structure and interpretation become hard to keep track of. Easily enough, such a program starts to look like a bowl of spaghetti, an amorphous mass in which everything seems to be connected to everything else. When structuring a program, we do two things. We separate it into smaller parts, called modules, each of which has a specific role, and we specify the relations between these parts.”

It is perhaps however, a new concept in the web design industry, particularly as it applies to content-driven websites. While many of us are aware of these terms – reusability, maintainability, and extensibility – the mental effort required to conceive and plan such a system (before even writing a line of code) can be daunting when compared with a more loose development approach where we let things take their own course. Particularly within the time and budget constraints of a typical client project. We may start with a rough concept of a system, and hope that the rest of the system will evolve and become clear as we progress through the project. In my experience however, this rarely produces good results.

Roadblocks to Modular Development

There may also be other external factors in the failure of an effective modular system. Chiefly, the idea of the “page template” and how that manifests itself in the design process and other sub-systems we employ. For example, as developers, we may want to write modular code, but if our designer is thinking and designing in “page templates,” then our ability to modularise design elements can only go so far and the full potential of the system will not be realised. Similarly, when we integrate our code with a content management system, we are often forced back into the realm of the page template again. WordPress for example, out of the box, is by its nature concerned with pages and templates. As Mark Boulton says:

“Huge swathes of the CMS industry are out of touch with how people are making and editing content.”

Another obstacle to modular web development that I often come across is the aftermath of “designing in the browser.” While this can be a highly effective way to prototype a site (and a lot of fun) the trial-and-error nature of the design process will undoubtedly yield inconsistent and wasteful code, that in an ideal world should be audited and rewritten before being deployed.

Drafting a Modular System

At the end of last year, several of us at Barrel set about drafting an all-encompassing modular methodology and workflow that would extend from UX and visual design, to development and content management. For the system to work we soon realised, all disciplines of the project team must be in the same mindset, and all of the sub-systems employed – from the design mockups to the architecture of the CMS – must be framed around the unit of the module.

For the system to work, all disciplines of the project team must be in the same mindset, and all of the sub-systems employed – from the design mockups to the architecture of the CMS – must be framed around the unit of the module.

The primary advantages of such a methodology, we anticipated, would be huge gains in project development time, power to the end-user (the client) in terms of flexible content management, and of course, ease of maintenance and scalability. We also expected that certain aspects of the process may be more time intensive, at least to begin with. Visual design for example, might require the designer to put an equal amount of effort into creating a robust design system. While we couldn’t be sure until we tried it out, we knew it would require a huge reconceptualisation of the way we work.

blog_module_team
Our multi-disciplinary team took part in regular discussions and sketch sessions before development began, to ensure a consistent approach across all aspects of the system.

While my UX and design colleagues worked to devise a design system of “components”, “modules” and “containers”, each relating to a flexible, content-agnostic design element, I concerned myself with the HTML, CSS, JavaScript, and PHP of these elements (our back-end was to be a heavily customised WordPress setup), and a system which would allow an end-user to join them together in any order or combination – just like Lego. In modular development, the system should be thought of as a specification, or set or rules, detailing how our modules are organised and interact with each other, how our file structure is organised, and how all parts of the system should be named for semantics and consistency.

As part of another initiative at Barrel, the development team had also been reviewing “best practices” for the various facets of the development process. Several technologies and patterns we agreed to evangelise included CSS pre-processors, Grunt.js, object-oriented JavaScript, and mobile-first stylesheets – all powerful tools for scalable, modular code. Combined with the power of the “Flexible Content Field” for Elliot Condon’s widely-used Advanced Custom Fields plugin for WordPress, we were able to forge ahead with the creation of a holistic modular system for content-driven websites.

Each one of our modules comprised of 4 distinct parts
Each one of our modules comprised of 4 distinct parts: A mobile-first LESS file, a PHP template-partial, a JS constructor, and an ACF layout.

Lessons Learned

Months later with several modular projects under our belt, the system (while still in its infancy) has exceeded our expectations. We are finally free from the constraints of the “page template” and all the wasteful, duplicated code that comes with it. The CMS itself has become our new prototyping tool. When we need to add a new feature to a site, we simply design and build a new module and drop it in. It then becomes available code to all other sites built on the system, should we need it for another project. We now have a library of modules that grows from project to project.

When we need to add a new feature to a site, we simply design and build a new module and drop it in.

With the time gained in cutting out much of the back-end and CMS development process, we are able to focus our attention more than ever to the front-end and admin user-experience. Our training and QA processes have also become much more standardised from project to project. No need to re-invent the wheel.

We also encountered a few surprises along the way. While reusable code may be economic in its ability to reduce new code written per project, it may also be more verbose when viewed as a single unit. Take for example the JavaScript for an interactive UI element. For this code to be truly modular, it must have as few dependencies as possible and should hypothetically be able to cope with an infinite number of instances in the same session, all functioning in isolation. More complex object-orientated architectures are therefore required, and often the code written may be twice the size of what could have been a few functions and variables in a less modular project. In some ways, the process of structuring an object in JavaScript, or a class in PHP, is a microcosm of designing a larger modular system.

At the outset, we believed that going modular in the CMS would require an all or nothing parting from template-based thinking. This wasn’t necessarily the case. While we went fully-modular for our WordPress “pages,” we found that many content types required a stricter template-based approach, or a hybrid of the two. Take for example a team profile. Users expect consistency when going from one profile to the next (e.g. bio, job title, photo), so the freedom of a modular approach served no purpose here. For something like a blog post however, more of a hybrid was appropriate. An image, excerpt and title might be mandatory, but within the content of the post, the user might pick from text, image and video modules in any order to construct engaging content.

Personally, the shift to modular design and development has been an exciting journey that has challenged me at both ends of the spectrum. High-level architecture on one hand, and low-level parts, mechanics and functionality on the other. The work has been educational and eye-opening. The principles of good architecture it seems, are universal. What applies to the smallest function or loop also applies to the largest structures and designs. The more robust the parts, the more robust the system. And while the system may be robust, it is not set in stone by any means. It will continually evolve as new projects challenge it in different ways. Because of its modularity, it is one system that is assured a long life span.

Illustration by Angel Ng

Popular This Week
25 Must-Have Pages for Your E-commerce Website
January 30, 2015

25 Must-Have Pages for Your E-commerce Website

By Yvonne Weng
New Shopify Theme: Mosaic
January 16, 2016

New Shopify Theme: Mosaic

By Peter Kang
Taking Control of Image Loading
July 29, 2013

Taking Control of Image Loading

By Patrick Kunka
Text-align: Justify and RWD
March 12, 2013

Text-align: Justify and RWD

By Patrick Kunka

Like what you’re reading? Sign up for the Barrel newsletter and receive updates.