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.
What About More Complex Stuff?
You follow the same principles for every other component you might need. The aim is to create modules which are standalone elements, independent of other modules. When combined, these modules will form templates, where you simply reuse the modules as needed and work towards completing your design.
For further reading on modular front-end development, I’d strongly recommend SMACSS, which is the architecture I tend to use on all of my projects, big or small.
Remember, the modular process is all about building, testing, and iterating. A module first gets produced in your editor, then tested in a browser, then iterated if needed. Repeat that cycle whenever necessary.
Involving the Client
Don’t forget the client’s needs — they want to be kept in the loop and get the confirmation that they’re getting their money’s worth. The beauty of this development process is that the clients can be active members of your team. You can safely show them the modules and they can overlook the development process and pitch in at all times to make the product better. They don’t have to wait for a static comp to be finished or a milestone to be reached before seeing real progress. If you take some time to explain the way modules work to your clients, they will have a better understanding and appreciation of the design process and the time spent building them.
The way I would usually go about presenting modules to a client is much like Bootstrap does it — setting up an isolated module along with its code is a great way to involve all the designers, developers, and clients into the process.
Use the modules you have built as building blocks for pages. For your index page, you might put the navigation module on top, a hero module next, some of the content modules next, then your footer at the bottom. Before you know it, you already have a page for an HTML prototype. But what is a prototype, exactly? I’ve always loved Leah Buley’s definition of a prototype from her great book The User Experience Team of One:
Functioning or semi-functioning examples of how the design should behave and operate once implemented.
By building a prototype, that is exactly what you will get in the early phase of the project — a semi-functioning website. Where static mockups and InVision fall short, HTML prototypes excel. The prototype serves as a perfect responsive deliverable for your clients. And once the client is OK with the look and feel of your prototype, all you need to do is polish it until it works the way it needs to. Build, test, iterate.
Reuse the Building Blocks
Modules and prototypes will enable you to reuse the code for the current project, but for future projects too. Tweaking a module from your last project can save you a lot of time — the modules you need in each project are often similar. I have a big library of modules which I often reuse: tabs, navigation menus, buttons, breadcrumbs, forms, tables, pagination, lists, etc. While the code of those modules is not exactly the same in all projects, good chunks of it can be reused, saving me a lot of development time. My advice for you is to create reusable modules for yourself too. Check out BASSCSS, Pure and Refills to get inspired.
Don’t get discouraged if switching to modular design and development takes time. Naturally, if modular principles are new to you, they will require a tweak of your design and development process, but the change may prove to be worthwhile.
The modular methods and techniques I covered in this article are just scratching the surface. Nevertheless, I sincerely hope this article has been useful and that it has intrigued you to dive into modular design and development.
Related: Getting Started with Modules and Modular Front-End Development