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.
The browser is the natural environment for a website, and sticking to
ideas made in a graphic editor may backfire.
●
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.
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.
References
This article was originally published on Toptal
About Author
Bojan Janjanin
Email: jordan.lyons@toptal.com
%20in%20India.png)
