What Every Programmer Should Know About Responsive Design

Image 1 [ Image Credit]

All Developers Must Have Basic Knowledge of the Front End

Software development has changed a lot in the last decade. Whereas once, developers worked on cultivating depth of knowledge and skills in a narrow area (like server side Java or .NET), they are now expected to be able to work across the entire development stack. Considering the diversity of technology involved, it is virtually impossible for any one person to master everything. But that's not what a Full Stack Developer is (IMO). A good Full Stack developer is someone who understands enough about all the layers of the entire stack, so they can comfortably learn on demand and work across them.

Keeping with this philosophy, I would like to introduce a very important concept in Front-End Development - Response Design. I will discuss the basic motivation and concepts that go into Responsive Design so you know what it means, and where to look for more information, when you need to learn it in-depth.

What is Responsive Design

Till a few years back most web browsing was done from the PC browser and consequently that is what most websites were designed for. But the last couple years has seen a steady increase in the number of mobile and tablets clients. Some websites report as much as 50% or more of their traffic comes from small sized devices. Most websites that were designed for the PC browser offered a sub-par browsing experience on mobile devices, since their layouts were not flexible enough for the smaller screens. An early response to address mobile users was to create a separate mobile website. If I remember correctly yahoo.com supported m.yahoo.com for mobile users. While it solved the problem of making websites more accessible for mobile users, this approach significantly increased maintainability hassles, because website designers now had to maintain two separate websites. It also violated a very important design principle; Don't Repeat Yourself or DRY.

Modular software development has long been known to the development community. It allows us to create one configurable software that can be deployed in different sites with varying requirements. The need of the hour was to create something similar for Front Ends as well, and Ethan Marcotte's seminal article on Responsive Web Design, eventually lead to a grouping of concepts which we now identify as Responsive Design.

Responsive Design isn't a single technology or product. Rather it's a group of concepts which together allow us to create websites that adapt according to the size or other properties of client browsers. At the heart of what makes this magic possible is a CSS3 feature called Media Queries. Very simply put, CSS3 has the capability to query the browser for certain properties (like its size) and apply special styles based -- defined in special sections -- on that information.

The image below shows how a website created using principles of Responsive Design looks on different devices.

Image 2 [ Image Credit]

Most websites have a logo, maybe a tag-line, a navigation bar, and a two (or three) column layout for the main content (which contain images and text). As we can see in the image, all these elements gracefully adapt to the smaller screen size of tablets and mobiles.

Key Concepts

As we mentioned earlier, Responsive Design is not a single piece of technology, but a set of techniques and concepts that work together. The key concepts that work together are:

Fluid grids are really about changing the way grids are sized from a pixel based approach to a proportion based approach. A responsive two column page layout would use percentages like 66.66% and 33.33% instead of 600px and 300px, for the main section and the right hand sidebar respectively. This allows the grids to resize according to the size of the browser window. This approach works well when we want to support the same layout on a smaller device (see Image 1), but it doesn't work very well when a screen is too small to support a multi column layout in any proportion. You can read this article on Fluid Grids for more information.
For small screens such as these, we have to modify the position of grid elements, or even hide certain elements altogether. CSS3 supports Media Queries which is simply a way for the stylesheets to apply special styles based on certain attributes of the browser (most notably it's size). It's very similar to if...else sections in a program. The code shown below in Code Example 1 will be applied when the browser size becomes equal to or exceeds 600px. The first line which identifies the media requirements with the @media keyword, makes this possible. We can also choose to define another section to apply a different set of styles at maybe 900px.
Along with fluid grids and media queries, a good responsive website also needs Fluid Images. The first thing we want to do is prevent images from scaling beyond their original size. This is easy to achieve by adding just one line in the style sheet: img { max-width: 100%; }. Besides this, using SVG images wherever possible is always a good idea, because they not only scale to any resolution, they also have smaller file sizes.

@media screen and (min-width: 600px) {

.content {

float : left ;

}

.social_icons {

display : block-inline ;

}

// more css

}

Code Example 1

Two Development Approaches

Just like there are two approaches to software design: top-down and bottom-up, we also have two approaches to responsive design: mobile first, and desktop first. In the mobile first approach, we first design our website and style sheet for the smallest device and progressively add functionality as well as design elements for larger devices. Whereas in the desktop first approach, we go in the opposite direction.

So, which of the two is preferred? Like most such questions, different people will give you different and equally convincing answers. But I like the way this tutorial from design shack explains the choices: philosophically it's about Graceful Degradation vs. Progressive Enhancement. According to the article (my opinion as well), it's better to avoid the Graceful Degradation approach, because if we start with the more permissive and powerful desktop environment, we are likely to leverage a lot of complex technologies and layouts which may not even scale down gracefully, forcing us to either re-implement them in different ways or to eliminate them entirely from the mobile solution. However, starting the solution with mobile platforms, forces us to think super lean and efficient right from the beginning. It ensures that we create a design which looks great on mobiles and upon that solid base, we add more design elements and features for more powerful devices. This way we don't even have to face the issue of whether a certain design element created for the desktop platform will degrade gracefully for mobile screens. Finally, since adding is always easier than redoing or cutting functionality, the path of Progressive Enhancement will most often lead to better designed products.

Front-End Framework Support

Since Javascript has invaded every conceivable corner of the universe except cosmic black holes (although a few weeks back there was news of a developer who tried to code blackhole.js, but got sucked in before he could push it to Github), we can't expect it to be far behind in Responsive Design solutions. And it's not. Popular frameworks like Bootstrap and Foundation give us responsive grids out of the box.

If you ask developers for an opinion of whether to use a Front-End Framework or build your own HTML and CSS, you will probably get strong voices for both sides of the argument, with both having legitimate reasons. But the truth lies somewhere in understanding the pros and cons and figuring out the right tool for the job. Frameworks provide Responsive Grids and a lot of styles to choose from OOB, reducing your design time significantly. They heavily tested across different browsers, so using one will decrease your own testing headaches. But on the flip side, frameworks are large, and can tend to make the website slower. The best approach is to make a list of features and objectives for your website and then do some research to determine if you will be better served with a Front-End Framework or with hand crafted HTML and CSS. This article by Smashing Magazine might be a good place to start, followed by this article by SitePoint which discussed several other frameworks like Gumby, Ink, and the ultra light weight Yahoo Pure CSS.

Additional Resources: