Getting Started with Modules and Modular Front-End Development

Everyone knows and loves Lego bricks. I was hooked on Legos when I was a kid, and I still love them today. You can assemble your toy from all kinds of Legos in all kinds of ways, one piece at a time. You can then start over and build a different toy from those same pieces. The possibilities are endless.

Modules on a website are a lot like Legos. Think of modules as Lego pieces which enable you to build your website. When you connect them together in the right way, they form web pages. To build websites like Legos, you have to think of websites as a collection of independent modules. This article will help you do just that with your front-end development and design.

Module Collages

When entering the design phase of a project, I tend to kick things off with assembling design inspiration collages and module collages. It’s a process much like Dan Mall’s, who calls these collages design deliverables for a post-comp era. Inspiration collages are collections of screenshots I present to the client, just to get a general idea of the visual direction we’re heading in. They are simply screenshots of websites both me and the client like.

Once we get the confirmation we’re on the same page in terms of the style, I can hop into my graphic editor (I prefer Sketch) and create module collages. These collages are collections of the most commonly used modules – buttons, forms, headings, paragraphs, lists, pictures, and so on. Module collages allow me to quickly create pieces of what the website will look and feel like.

Here is a part of a recent module collage of mine, an example of a button I designed in Sketch at the start of a project:

Perhaps you’re wondering when static comps and presenting pixel perfect designs to the client come into play. They don’t — I’m skipping those almost entirely in my process. Skipping that part of the process enables me to get into code very early in the project and code prototypes (I’ll get to those soon), or in other words, design in the browser. Here are some of the advantages of designing in the browser:

• The browser is the natural environment for a website, and sticking to ideas made in a graphic editor may backfire. It is only natural to test and make design decisions in browsers. You’ve heard it before, you’ll hear it again — it’s not about how it looks, it’s about how it works.

• There will always be design inconsistencies between the static mocks and what you end up getting in the browser once they are translated into code. To avoid those inconsistencies, jump into the code editor and the browser to solve real design problems.
• Static comps might not get the right message across. The look and feel will be a lot different once you integrate the interactivity — like the hover states, transitions, and animations.
• Instead of spending hours upon hours designing several static mockups for several resolutions, I can save a lot of time by going into code early. Tweaking the CSS enables me to quickly demonstrate the changes and responsive aspect to the client on various devices — smartphones, tablets, etc.

So, save time and open up your code editor and the browser to start creating the UX as early as possible. In my experience, most clients will ask for a full mockup of a page or two before we can proceed with coding, and that is completely fine. It’s important for the client to have a good sense of the future design. I usually use InVision, which is a great tool to keep track of the early mockups, the changes, comments, and more. However, it’s very important for clients to understand that Sketch and InVision won’t get them very far.

Building the Modules for Front-end Development

Once the client is happy with the module collage and the mockups I have designed, I can start coding and define the real look and feel of those elements.

Modular design is intertwined with modular development in an iterative process. I code up a module, then try it out in the browser to see how it works, then iterate if needed. Again, this process is much like building the Legos — you basically design and develop at the same time and try out different variations until you feel good about it.

I often start the development of the modules with building something simple, like a button. Imagine you’re building one yourself and you need to code up an orange button, generally used for a contact form. Here’s what you might come up with:

.submit-button { 
	background: orange;
	color: #fff;
	padding: 10px 20px;
	font-size: 16px;
}

<a href=“#” class=“submit-button”>A link</a>

Simple enough, right? You’d apply the .submit-button class to your HTML and that’d solve your current problem. Now, what would happen when you need to create a new button, just like that one, but with a blue background color? You’d probably copy that exact class, then change the class name and the background color. Quick and dirty. Now, imagine you then need to use the same button, but with an orange background. You can see where this is going — you may end up with a lot of CSS being repeated. On a super small project, this may not become a real issue, but on larger ones it probably will. Before you know it, your CSS gets bloated and difficult to maintain.

If you’ve ever developed a medium to large-scale project, you’ve no doubt experienced your fair share of headaches. Those may have been caused by any of the following reasons:

• Code that is messy, inconsistent, hard to scan and understand.
• Bloated code and XXL CSS files with a lot of duplication.
• Code that is difficult to maintain.
• The lack of separation of structure and skin.

Don’t worry, you’re not alone. I’d bet all front-end developers have experienced those painful issues from time to time, and probably many more. I can safely say I’ve had plenty of projects in the past where I’ve encountered all those typical problems.

One way to avoid or minimize those problems is to build in a modular way.

The Modular Button

How to code up that button in a modular way? A modular approach would be to write code which you can reuse. Remember those Legos, which can be used and reused all over again.

.button {
	padding: 10px 20px;
	font-size: 16px;
}

.button-orange {
	background: orange;
	color: #fff;
}

<a href=“#” class=“button button-orange”>A link</a>

What we’ve done is a clever separation of styles. The .button class contains the styles every button in your project uses, so you don’t have to repeat it. The .button-orange class uses only the styles relevant for the orange button. You would do the same for all other buttons and define their background and text colors.

Your button module could end up consisting up several independent buttons, ready to be used whenever you need them.