Skip to main content
By now the term Responsive Web Design (RWD) has become fairly common in the digital industry. As developers we expect three separate designs for a single template; one for mobile, one for tablet, and one for desktop. With these visual declarations as well as responsive frameworks, such as Foundation and Bootstrap, it’s easy to hit-the-ground running. But, what happens when you add a Content Management System (CMS) to the mix? How do we create a solid responsive framework, modular in nature, in which the client has the ability to create his or her own Picasso?

Change Your Frame of Mind

Before you begin development, it is important to change your frame of mind. As developers, we have a surplus of knowledge relating to web design and sometimes fall into the expectation that clients know, or should know, about half of what a developer knows. We must erase this expectation. A CMS is designed to be user friendly and capable of supporting a variety of editors — some more web-savvy than others. Because of this spectrum of users, a developer must consider how a potentially non-web-savvy person perceives how a site is built, and how they might execute building their own pages within a CMS. It’s time to put ourselves into their shoes. During the design phases, clients are exposed to the page structure and the content within it; page patterns start to form and the final templates are established. For RWD and CMS builds, we have to assume that the client will use these templates simply as a guideline — mixing and matching content styles throughout their pages. In the past, CMS systems restricted which content styles could be used within each template, but most modern CMS systems remove this restriction. Therefore, before development begins, we need to start thinking of our templates in the most modular way possible. The first step is to review the templates and highlight repetitive content blocks (which we will define/refer to as modules).

Review Templates & Define Modules

Let’s assume that there are three template types that the UA/UIX has developed (other than the homepage which has its own unique structure); a one column, two column, and three column template (Figure 1).Desktop Templates

Figure 1 – Desktop Templates

Among these three templates we can formulate a list of the different types of modules that appear.  In Figure 1 above, we can see that there are 8 different types of modules—labeled 'a-f'.  Modules 'a' and 'd' define the header and footer, while modules 'b' and 'c' define clear content blocks throughout the three template types.  In the two and three column layout we can see additions of left (e,f) and right rail (g,h) modules.  Normally we would build these templates and modules to the structure the UA/IX designer has developed.  However, since the client will ultimately build the pages in the CMS, they may likely develop different layouts than what we had originally considered.

Desktop Templates, User Defined

Figure 2 – Desktop Templates, User Defined

Many of the modules have shifted to different template types.  Modules ‘e’, ‘b’ and ‘c’ have shifted and relocated into different templates. Because of this possible scenario, we need to make sure that our modules are built with fluidity.  Thankfully, RWD allows for this fluidity — a module can be built to independently fit any width that can fit into any space. By considering that the end user is likely to shift content around the page,  we gain an understanding of how they may ultimately build their pages using modules. Now we can begin writing our HTML and CSS to deal with this fluidity from a template and RWD prospective.

Create Simple Structures

Our html for our modules should be fairly simple markup.  Start by creating a general page that contains all of your modules.  Since these modules need to work in any column width on any device, separating them from the actual design helps with development.  Spending a little more time upfront to develop this way will save you lots of time, and headaches, down the road.  Let’s use module g in Figure 2 above as our markup example for the start of this template.  Below I’ve defined it in more detail (Figure 3).

Module Example

Figure 3 – Module

We’ll start with the base of <div class="module"></div> to define any content pieces that we have deemed to be modules during our initial template investigation. A simple html structure might look like this:
<div class="module">
<h1>Title Lorem Ipsum Dolor</h1>
<img src="http://placehold.it/300x300&amp;text=fpo" alt="" width="100" />
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean consequat blandit orci eu lobortis. Etiam sodales, sapien non pretium.</p>
<a href="#">Learn more ipsum link</a>
</div>
From there we can begin to specify the markup based on unique elements of the module.
<div class="module callout with-header blue">
<div class="inner">
<h1>Title Lorem Ipsum Dolor</h1>
<img src="http://placehold.it/300x300&amp;text=fpo" alt="" width="100" />
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aenean consequat blandit orci eu lobortis. Etiam sodales, sapien non pretium.</p>
<a href="#">Learn more ipsum link</a>
</div>
</div>
Noticed that we’ve added the additional classes of “callout”, “with-header”, and “blue” to the module as well as a wrapper with the class of “inner”. Note that we did not use a class called “right-rail” because even though the designer had originally intended these modules to exist in that placement, they client may not use them there.  If the client places this module in the left rail, the markup with the class of “right-rail” no longer applies.  It is important to follow a naming convention that is descriptive to the module and it’s features.  The classes applied to module 'g' allow us to define elements specific to any callouts (larger font size, link treatment, etc) as well as any modules with headers or any modules with a blue theme applied. Now lets define what the CSS will look like.  We know this module needs the following parameters: the width and height need to be fluid to fit in any column and the image needs to fit 100% of the container in mobile (as defined by the designer in their mobile designs).  We also know from the markup that this module has a header, and the theme of this module is blue. For these scenarios, the CSS would look as follows:
/*base module styles*/
.module {
font-family: arial,helvetica, san-serif;
font-size: 16px;
color: #333;
width: 100%;
display: block;
}

.module p {
font-size: 90%;
}

/*module with header styles*/
.module.with-header h1 {
display: block;
padding: 10px;
color: #fff;
}

/*blue themed module styles*/
.module.blue.with-header h1 {
background-color: #4da3da;
font-size: 100%;
}

.module.blue a {
color: #4da3da;
}
/*callout module styles*/
.module.callout img {
display: block;
float: left;
padding-right: 20px;
width: 20%;
}

@media screen and (max-width: 767px) {
.module.callout img {
padding-right: 0px;
width: 100%;
padding-bottom: 20px;
}
}

.module.callout a {
position: relative;
text-decoration: none;
}

.module.callout a:after {
content:"";
width:0;
height:0;
border-top:6px solid transparent;
border-bottom:6px solid transparent;
border-left:6px solid #4da3da;
position: absolute;
top: 5px;
margin-left: 5px;
}
This CSS would look like the below on a desktop:Desktop ModuleAnd like this at mobile widths:Mobile ModuleWe can re-size the browser independent of any template structure to see how this module may function at different sizes.  This same HTML/CSS development concept can be applied to the remaining modules (a-f).

Build out Templates and Relax

Once all the modules have been developed in our general html document, they are ready to be placed into the predefined templates laid out by the UI/UAX designer in Figure 1 above.  It is also good practice to move the modules within these layouts to make sure they are resizing appropriately as a preemptive notion to what the client might do.  Here, you can also set specific styles based on whether certain modules are placed within the left, center, or right rails. After all the templates have been built, we can sit back and relax and let the back-end developers do their job. Once our development has been loaded into the CMS, the client is ready to populate their website.  If we, as front-end developers, have done our job correctly, this process should be fairly painless. We've developed the proper tools for the client to paint their masterpiece - there should be minimal effort to revise our CSS to fit their needs.  So go ahead, have a glass of wine (or beer if you prefer), and enjoy watching the creation!  

Further Reading