The web is responsive on its own by default. It's us that's been breaking it all these years by placing content in fixedwidth containers - Andy Hume.
While designing websites in a responsive manner is becoming a must lately, we should not forget that there is no universal correct solution for anything, and this also applies to web design. While it can be a massive advantage and attractive feature for the enduser, it can also prove to be a drawback if not used properly. In this presentation I propose taking a look at the DOs and DON’Ts of responsive web design: how it should be used, when it should be used, and most importantly: when it should be avoided.
The importance of the presentation tier is given by the fact that it is responsible with the user interaction; it is what the enduser sees after all the processing that the application handles; the presentation has to match the complexity of the rest of the application. It must be simple, intuitive and light even though the system is heavy or complex, because the enduser does not care about the load of the system or it’s elaborated structure; his desire is to navigate as straightforward and fast as possible through the application.
As far as web applications are concerned, the front end tier is the content rendered by the browser. This content can be static, dynamic, but it is usually a combination between the two. There are of course a lot of challenges in developing content for browsers, because of the numerous types of browsers and their versions, many having certain traits. There is no correct number of principles to take into consideration when creating the interface or design of a software product, but there is one on which everyone agrees: simplicity.
An important aspect of styling is checking across several browsers and to write concise, terse code that is specific yet generic at the same time and displays well in as many renderers as possible [Cod09].
CSS can be used to display the document differently depending on the screen size or device on which it is being viewed. Coding towards this kind of document flexibility is known as responsive web design. The aim is to craft sites that provide an optimal viewing experience independent on the size of the display used to render them. In addition to this, the navigation must be done with a minimum of resizing, panning or scrolling.
A website that has responsive web design adapts the layout to the viewing environment (as seen in Figure 1 ) by using fluid grids, flexible images [Mar11] and CSS3 media queries. Simply put, media queries are “if clauses” for the browser that renders the page: it knows that some styles have to be applied only if a condition is matched (usually the condition is put on the width of the screen).
The main concern with this concept is that designers and developers define “responsive” differently, which leads to communication problems1. Hence, let’s see how the term was defined when it first appeared, in 20102: Ethan Marcotte defined it as providing an optimal viewing experience across a wide range of devices using three techniques: fluid grids, flexible images and media queries.
We must understand that the main goal of a mobile web experience is to be lightning fast and provide a compatible user experience on all devices, and most websites fail at the first part of the statement: performance. Responsive web design was never meant to “solve” performance, which is why we can’t blame the technique itself [Fir14].
A new movement is starting to emerge, called by some “responsible responsive web design”, which suggests that responsive design shouldn’t be the only solution for mobiles, but used together with other techniques, such as conditional loading and responsiveness according to group.
Media queries are usually either stored in a single CSS file with multiple
@media declarations, or in multiple CSS files linked to from the main page via media attributes:
< link rel="stylesheet" href="mobile.css" media="(maxwidth:480px)">
Although most tutorials and websites use the first technique, it’s wrong. Furthermore, there are some who think that the second options only loads the corresponding CSS for the resolution of the device this is also wrong. Both of these solutions are wrong, simply because it makes the browser load all the possible CSS and then parse them to see which instructions to apply. This affects performance because slower mobile browsers are parsing both mobile and
“What we mean when we say responsive”, Lyza Danger Gardner, A List Apart, March 2014
There is no concrete solution for responsive web design (yet), but there are some tricks that help enhance performance when developing responsive solutions:
The short answer is yes, you should be responsive when designing and implementing websites, but the methods of doing it have to change. Responsiveness is important especially because of the exponential increase of mobile users, which slowly but surely will overcome the desktop ones in the years to come.
The answer depends on the nature of the content, though: if there’s too much content that needs
to be displayed on the phone, it’s better to keep a simple version of the site for mobile and provide an app to deal with the complexity of your system (banks usually follow this approach, for example). Relying on a responsive website versus a mobile app is a business call3, rather than a technical one.
The ultimate goal for a website should be “happy users”, and not “being responsive”. When you know your goals, you can decide which tools and techniques are best to achieve them. Users won’t be happy without a highperforming website [Fri14].
Keeping the above in mind, in order to end on a happy note, here’s a quote from Brad Frost: “Your visitors don’t give a s**t if your site is responsive” They don’t resize the browser and they don’t care what responsive is. They want something fast and easytouse.
[Cod09] Ivan Codesido, What is frondend development, The Guardian, September 2009
[Fri14] Maximiliano Firtman, You May Be Losing Users If Responsive Web Design Is Your Only Mobile Strategy, Smashing Magazine, July 2014
[Mar11] Ethan Marcotte, Flexible Images, A List Apart 328, June 2011
by Ovidiu Mățan
by Axente Paul
by Olimpiu Pop
by Ovidiu Mățan