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.
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.
“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.
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.
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