Subscribe by Email

Your email:

Brand & Capture

Current Articles | RSS Feed RSS Feed

Responsive Web Design: Is it the Future or a Feature?

 

responsive web designWhat if you only had to build one website design and it would fit all devices, big or small? You can, with a Responsive Web Design. Responsive Web Design (RWD) essentially indicates that a website is crafted to use W3C CSS3 media queries with fluid proportion-based grids to adapt the layout to the users viewing environment. While it is still in the early stages of acceptance, this new standard in web development could be the future. Here we get you up-to-speed.

The Inception

It all started with an article by Ethan Marcotte on A List Apart. It’s hard to talk about responsive design without mentioning Marcotte. The thinking was new for web designers because the status quo has been to re-design and/or create multiple versions of a single website for several devices. For example, many clients will often pay for a new website, then a mobile version, then an iPad version, and on and on. But this isn’t the way forward; there is no way to anticipate what new device will hit the market and how it will affect designs. What Marcotte proposed was addressing the ever-changing landscape of devices, browsers, screen sizes and orientations by creating flexible, fluid and adaptive websites. In short, a one-size-fits-all web design.

In the very aptly put words of Jeffrey Zeldman: "It’s what some of us were going for with “liquid” web design back in the 1990s, only it doesn’t suck."

The Case for RWD as a Universal Standard

Ever since the days of CSS 2.1, designers have been able to get a modicum of device awareness through media types. Example:

<link rel=”stylesheet” type=”text/css” media="print, handheld" href=”path/to/print.css”>

However, most devices and browsers never really took this option into account, leaving web developers with using media types in the dark, often implemented imperfectly or just completely ignored. But thankfully, WC3 came to the rescue in CSS3 with media queries as a part of its specifications. Now, the designer could inspect the physical characteristics of the device rendering our work. For Example:

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

.special-content {
float: left;
margin:10px 5px 17px 5px;
}

.social_icons {
display: none
}

// and so on...

}

The CSS Object Model (CSSOM) working group at the W3C also created media query listeners, which provide an API for responding to media query changes. Instead of having to poll for changes or load several versions of a resource, you can use the API, for example, to download images only of a particular size when a media query match is triggered. However, only Firefox and the Internet Explorer 10 Platform Preview currently implement media query listeners, so they aren’t a reality for standard web development and design right now.

A Flexible Grid Layout is another key component behind creating a Responsive Web Design. Instead of designing a layout based on rigid pixels or arbitrary percentage values, a fluid grid is more carefully designed in terms of proportions. This way, when a layout is squeezed onto a tiny mobile device or stretched across a huge screen, all of the elements in the layout will resize their widths in relation to one another. However, with most company’s using Content Management Systems like Joomla!, Wordpress and Hubspot to build their websites, sometimes a fluid grid won’t be supported through their rigid back-end dimensions (which developers don’t often have access to) or a lack of support for HTML5, CSS3 and others.

The ultimate purpose is adapting to the user’s needs and device capabilities. Suppose a mobile user will be viewing your site on a small screen. Taking the user’s needs into account doesn’t just mean adapting your content to the screen size. It also means thinking about what that mobile user will require first when visiting your site and then laying out the content accordingly. Maybe you’ll present the information in a different order. Don’t assume the user won’t need access to all the site information because she’s on a mobile device. You might need to change the fonts or interaction areas to respond better to a touch environment. All these factors influence Responsive Web Design.

The Case for RWD as a Feature

Of course, Responsive Web Design is not without its detractors, who argue it is more of a feature than a standard. Their argument is that any well-designed, non-responsive site looks great in mobile Safari. Yes, you have to double-tap and zoom in. Yes, it serves up content that, in some cases, is useless and weighty to the user on a mobile device. But while a nicely designed, non-responsive site isn’t the best user experience by any means, they would also submit that it isn’t a bad user experience either.

Also, don’t forget the golden rule in the development world: time = money. Building and testing a responsive site takes considerably longer than doing the same for a static site. Fluid layout means more layout break points; serving up specific layouts to specific devices (eg. desktop browser, tablet in portrait mode, smartphone) means more wireframes, more mockups, and more testing. Using advanced web design techniques – the foundation of Responsive Web Design is the CSS3 media query declaration – means even more testing and problem-solving on older browsers. Yes, responsive design takes much more time, including the afore-mentioned maintenance or dealing with a client-handled CMS.

So based on the detractor’s thinking, Responsive Web Design is a feature to be up-sold to prospective clients as ultimately a more affordable solution to optimizing for all the devices out there. The key selling point is that they won’t need a mobile site, or an iPad site, etc, if the client is willing to pay more up front and offer more development time for their website. This allows you to keep your base web development prices low, instead of remodeling your entire pricing structure to account for the increased development time.

What does this mean to you and your company?

The truth is no one really knows where this is going. But at the very least, you are now up-to-speed with this topic as it continues to develop. The idea definitely has traction among developers around the Web. But will it be a practical solution that can be universally developed for the large number of SaaS and CMS solutions out there? Only time will tell.

The bottom line question for now - should I commission my new or redesigned website to use responsive web design? For now, we would advise against it. The majority of web browsers are not up-to-speed with HTML5 and CSS3, the building blocks of RWD. Same with the vast majority of content management systems. We assume that all of the above will eventually move to the new standards, but when and how consistently? Again, only time will tell.

What do you think? Have you had any positive or negative experiences with Responsive Web Design? Let us know in the comments below.

Photo credit: axbom



Jesse Pennington Author BioJesse is a Web Developer at Kuno Creative who regularly contributes his technical expertise to Kuno's blog. He carries a Master of Science in Mass Communcations and has over 3 years of experience in web development and design.



Mobile Websites, Mobile Applications, SMS/Text Messaging and QR Codes

Mobile Inbound Marketing Video



Comments

I just completed a new site design incorporating mostly percentage sizing versus fixed pixel. It's the first project I've actually taken mobile and tablets into consideration. It's also the first project where I beta tested the layout on 6 or more screen resolutions and the four major browsers (I know, I'm about 10 years behind on proper testing for compliance... lol). 
 
What I found was that most phone browsers allow the user to set their phone browser to DESKTOP agent mode... which simply allows the user to view the site and the content as though they are in desktop mode. While its nifty to do so, it still doesn't address the fact that many don't even know that the feature exists or would even think to switch to that mode. Additionally, it also doesn't factor the extreme variation for screen resolution issues even when in DESKTOP agent mode. 
 
I beta tested the site until 80-90% of the content was visible and viewable in mobile agent mode... which basically meant that the viewer would have to deal with some scrolling and zooming to see the site's content nicely. However, it's a small compromise for the cost benefit of not having to develop multiple versions of CSS sheets or eliminating site content that may be too heavy for mobiles. 
 
In addition, CMS systems are a great selling feature to clients who want to manage their own content after site launch, but this blog post was great in that it addressed the compromise and reality... most frameworks aren't flexible enough to let developers adjust for these kind of issues. Plus the reality is that most out of the box CMS solutions have huge simplification for common content deployment, but huge downfall for customized content deployment... which begs the question of whether it makes sense to build a corporate site with the handcuffs of an inflexible platform that makes assumptions based on the general uses of sites online. 
 
As a custom developer for my clients, I am currently facing these two mentioned issues (mobile and CMS) and really being challenged to address the cost versus benefit ratio since some content is not always crucial for mobile viewing and/or not changing enough to deal with a full fledged CMS system. The other issue is that CMS training for client employees is often given to those who are techno-phobes and I have found that the customer support after training takes as long as if we could make the webmaster updates ourselves. It's a delicate balance. 
 
Good blog... good information.
Posted @ Monday, April 16, 2012 8:58 AM by Patrick
Thanks for comment! You are speaking my heart on this issue. The delicate balance of our development time versus the solutions we offer is a difficult one. I can't tell you how many times I wished I would've just tried to sell a support contract instead of trying to train a client on a CMS.  
 
As a developer there are times where I could kiss a CMS like Hubspot or Wordpress for making what would be complicated a simple click and adding of a widget/module. But in the same breath I'll curse its inflexibility when it won't do what I want and I can't get to the backend. Usually those CM systems will claim they are already optimized for mobile display, but you and I know it never quite works out that way. 
 
Ironically, at the end of his book, "Responsive Web Design," Ethan Marcotte says very clearly, “...most importantly, responsive web design isn’t intended to serve as a replacement for mobile web sites”. He really leaves it up to the designer to determine whether or not responsive design makes sense for their project.  
 
The other thing is that while Browsers are trying to move forward like Chrome with built in apps and SAAS and IE10 coming soon with it's X-Box Live/Windows Phone design and integration, there are so many businesses reliant on out-dated and crude software systems. Because they are tied to these systems they cannot updated their Computers and OS (i.e. Windows 2000, Windows NT, XP, etc) their browsers will forever be out-dated. The lagging economy also doesn't help meaning companies are less likely to overhaul their entire system and more likely to squeeze every last dime out of their system and employee's. So as developers, I'm not sure we'll be able to develop for all browsers and systems in the near future. At some point, we're going to have to make difficult decisions on whether or not we'll leave money on the table for the sake of progress.  
 
Anyway, great comment and thanks for reading!
Posted @ Monday, April 16, 2012 9:26 AM by Jesse Pennington
Wow! I've been looking for this information. Technology is changing so rapidly that people don't have the time to keep their gadgets or systems up to date with it. Is it changing too quickly? Time will tell.
Posted @ Saturday, April 28, 2012 12:52 PM by Virginia
Comments have been closed for this article.