Notice: Undefined index: order_next_posts in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 194

Notice: Undefined index: post_link_target in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 195

Notice: Undefined index: posts_featured_size in /nas/content/live/gadgetmag/wp-content/plugins/smart-scroll-posts/smart-scroll-posts.php on line 196

The art of responsive design Pt2

Part 2 of this extensive responsive design feature takes a look at structure, typography, navigation, images and testing tools, Screenfly, Viewport Resizer and Adobe Edge Inspect


We’ll begin building our simple layout, putting in place the div modules we’ve identified from our wireframe. Any base CSS styling can go into our style.css sheet. Although Skeleton already has the container style covered, we’ll add a specific class from the skeleton.css to each of our other ids, based on how many columns we wish each module to occupy. For example, we want the header to span the full 960 width, so we mark it:

001< div id=”header” class=”sixteen
 columns”>< /div>

The same applies to our navigation bar, but the content and sidebar divs must sit side by side; at least in our PC layout. So, we divide between the 16 columns, according to how wide we want each to be:

 001< div id=”content” class=”eleven columns”>< /div>
 002< div id=”sidebar” class=”five
 columns”>< /div>

Feel free to go into skeleton.css and change margin and column widths to suit your needs. For example, trimming 5px from the margin for each column at the base 960 grid level allows expansion of the column widths by the same amount. You can play around with the values until you have the layout you require.
Our basic layout is ready for viewing in the browser. Reduce the size of your browser and you’ll see that it already adapts to the reducing screen size, but there are still some details to iron out, specifically the logo image, text, and navigation.


We need to decide how our text will be handled as it moves between different screen sizes. Common practice has been to declare the base font size in the body tag using a pixel value.

 001 body {
 002 font-family: Arial, Helvetica, sans-serif;
 003 font-size: 16px;
 004 color: #000;
 007 h1 {
 008 font-size: 42px;
 009 }

However, for the purposes of responsive text we will shift to a relative value. If we declare a base value of 100%, which most browsers will interpret as 16px, we can then adjust all our text relative to this 100% using the em value.

 001 body {
 002 font-family: Arial, Helvetica, sans-serif;
 003 font-size: 100%;
 004 color: #000;
 007 h1 {
 008 font-size: 2.625em /* 42px / 16px */
 009 }

Assuming our 100% font size is 16px, we can calculate the em value of all our text using this formula:

 001 Target / Context = Result
 002 The target value is 42px and the context value is thevalue of 100%, which equates to 16px.
 004 42 / 16 = 2.625

Hence our h1 value of 2.625em, with the calculation commented after the value as good practice.
With our 100% base value declared, we can start entering relative values into media queries to make certain our text never looks too big for the area it occupies. Let’s add some media queries to our style.css to target additional device widths. We want to address text at the mobile level. We can place in a reduced percentage for the body font to target all text:

 001 @media only screen and (min-width : 320px) and (max-width : 480px) {
 002 body {
 003 font-size: 70%;
 004 }
 005 }

But this will leave the main content text unreadable, so let’s enter specific values to target only certain text:

 001 @media only screen and (min-width : 320px) and (max-width : 480px) {
 002 h1 {
 003 font-size: 1em /* 16px / 16px */
 004 }
 005 }

In this way, we can be sure that only the text we need to resize will do so.


Since putting together the wireframe and working with the actual HTML in the browser, an issue has emerged – ­the size of the navigation links in a reduced-width nav bar. Though they sat well side-by-side in the large
screen version, we’ll stack them for mobile viewing.
This makes them larger and easier for chubby little fingers to tap.
The easiest way to achieve this is to change the display:inline value of the base layout to display:block for the 320 width media query. Then add a text-align:center to the nav div. More complex navigation styles will obviously require more complex solutions, and there are a number of jQuery plug-ins such as TinyNav.js that will cut out the heavy lifting for you. The point is that by using our media queries we are able to present a completely different navigation format for the mobile browser, and that is one more suited to the single finger than the cursor.


Our logo is currently an image, and while the client may enjoy seeing their logo writ large upon the small screen, we (as designers who know what we are doing) would be much happier if it fit more snugly to the left and allowed room for the Phone number to sit alongside it, as per our original design. We, therefore, add that handy img value to our style.css and make sure our logo scales down accordingly.

001 img {
002 max-width:100%;
003 }

Now give #logo a width of 40% and watch the results. While our fluid grid is doing all the work for us, we can exert more control over certain elements by giving them specific widths in percentages. By giving the logo div a percentage width, we are telling it to reduce itself in relation to the screen and, in tandem with the img value, reduce the image as need be. Now we have a greatly reduced logo when viewed at mobile size.
It should be noted that while this is a tried and tested method for resizing images in responsive designs, the issue of load time for larger images on smaller browsers is something that every designer will confront. It makes little sense for someone viewing an image on a 320 screen to wait for a 1,420pxl wide, hi-res image to load in the postage stamp–size space allotted it. Not to mention the data usage involved.
Thankfully there are some neat solutions for this problem, including a number of JavaScript snippets, such as Adaptive Images. This snippet sits in the and utilises the cookie function and .htaccess file to either call from a series of stored images at different resolutions or intelligently resize the image and send it. Further to that, W3C have recently proposed a new element and srcset attribute for enabling multiple image loads by specifying media queries in the HTML for various image resolutions.

Time to test

One of the more daunting, time consuming tasks facing anyone building responsive websites is the testing phase. In the days before mobile devices really embraced web browsing, the designer was able to test all eventualities on one screen, and the worst of that was viewing the site on Internet Explorer. These days the designer needs to know how the site will view on a number of different screens, and that number is getting greater every year.
Some designers argue that if your site is built well enough and is responsive in the truest sense of the word, rigorous testing is not only unnecessary, but misses the point. The site will do what it is supposed to do and adapt to any screen it encounters. While this sounds like an attractive proposition, it is somewhat idealistic. Unpredictable variables will always arise. Testing is vital.
It’s a fair bet that anyone building a responsive website will have spent a lot of time dragging the edge of their browser window to watch the site adapt to new widths. It’s quick, it’s simple and it gives you an instant idea of how your site is working. But it can only tell you so much and isn’t a true representation. In an ideal world, designers would have access to a comprehensive suite of test devices for quick debugging. But beyond the top design agencies, this is highly unfeasible. Clearly, testing on the intended hardware will always be the perfect option, but failing that, there are many alternative options worth considering.


Simplicity is the word with QuirkTools’ browser simulator. Once you have pasted in your URL, Screenfly opens your site in a ten-inch netbook window and has a simple menu system at the bottom for alternating between resolutions. Choose first by device category, from mobile to television, and then by model and brand.
Screenfly doesn’t offer the breadth of choice that you get when picking devices with Viewport Resizer, but it covers enough bases to help you gauge the success of your site. It also boasts a clean interface, smooth transitions between devices, and as such is a joy to use. These are just a few of the tools available to the web designer looking to give that website a quick road test.
They may not be able to answer all the questions in the same way hardware tests will, but they can make testing a little less painful. Testing will always be an important part of the design process, no matter how site building techniques develop along the way. Increasingly, there will also be the consideration of multiple browsers on a single device. For example, some websites display differently on Android versions of Chrome and Dolphin, to name but two. The minefield designers need to traverse expands apace. Thankfully, so do the tools at our disposal.

Viewport Resizer

Malte Wassermann offers a quick and easy way to view your site in various dimensions with the Viewport Resizer. It employs a simple bookmarklet you can add to your toolbar and implement with one click. It then resizes the window to whichever device specification you request from the menu.
Viewport Resizer is fully customisable. Simply choose the device widths, either from a list of devices or from a set of generic dimensions, and build the bookmarklet you want. It also offers orientation options for all sizes and scrolling within the window. It’s not exactly the most accurate replication of device UI, but for the development and preliminary testing stages, Viewport Resizer is a great aid.

Adobe Edge Inspect

Formerly known as Adobe Shadow, the Edge Inspect application allows y
ou to connect all your devices wirelessly, display the website, and view changes concurrently, as they are made from the central PC. It also allows simultaneous screenshots from all devices for quick comparison. Edge Inspect requires a separate installation on each device, and while it is an excellent way to test and debug your site for multiple devices, the major drawback is that without the actual devices it is useless. Under the guise of Shadow, the application was a free Beta release. However, Adobe now offers a free version, which only allows one device to be tethered at a time, and the full function version, for a monthly fee.