April 7, 2014

How to Make Your Website Mobile Friendly with Responsive Design

The 14NTC was a great time for me and everyone else I ran in to. I especially appreciate the tenacious group who attended the “Make it Mobile!” session that I did with Niki Hammond from MSDS on Saturday, March 15.  We had a good time presenting about Mobile and Responsive Design, and similar to every session I attended, the Q&A was definitely the best part.

Responsive Web Design is the latest in a long line of terms that have really caught on and, depending on who you ask, either signals a complete shift in the way that we work, or describes some cool new techniques to consider when designing and building websites.  I tend to fall into the first group to such an extent that I believe a year from now, what we are now calling “Responsive Web Design (RWD)” will simply be called “Web Design.” 

We need to call it responsive now because it represents a big enough evolutionary leap to require us to define specific techniques that we could use to accomplish it, but the more we do responsive sites, the more it sinks in that there’s really no reason to not make a website responsive.

That said, here are a few important terms that may help to clarify what I’m talking about when I say “responsive.”

Adaptive Web Design uses a pre-defined set of layout sizes based on screen size. You can make informed decisions based on your site analytics that tell you which devices people are using when they visit your site, and then targeting those devices.  There will likely be some device detection going on here as well, and some amount of server-side changes depending on the device.

Responsive Web Design on the other hand, is comprised of three things: a fluid grid, flexible images, and media queries (CSS rules that kick in at certain viewport widths, or based on other properties of the device viewport).

Finally, “responsive” (little “r”) is a less strict way of describing this new world of design thinking, along with some of the techniques used to accomplish them.  RWD has a real definition forwarded by Ethan Marcotte, this “little r” version is more a feeling; a sensibility; an ethos.

“Today, anything that’s fixed and unresponsive isn’t web design, it’s something else. If you don’t embrace the inherent fluidity of the web, you’re not a web designer, you’re something else.”

-Jeffrey Zeldman

What Set’s Responsive Apart from Adaptive?

 A site should work on any screen size you can throw at it. It’s not about the specific device being used, it’s about the size of the screen.  The web is responsive by nature.  It’s always been responsive, and it is through our own design decisions and coding practices that we have built sites that were not responsive but were, rather, trying to mimic the print world with which we were more familiar. 

Being successful with RWD means accepting that you can’t control everything.  It’s a change in philosophy as much as it is a change in design and coding practices.  It’s about UX folks, Designers, Front End Developers, Tech Leads, Software Engineers, all of us, understanding how web pages behave and using that to our advantage when planning and designing the experiences we ultimately build for our target audiences.

RWD is less about the techniques and more about the process

Those of us that are doing RWD recognize that it’s not something that just happens after the site has been planned and designed, and is now ready to be built.  It involves a sea change in the entire process we follow from the first workshop with clients, to pushing the new site out the door onto the big scary Internet.  Check out Jared Spool and Jason Grigsby talking about how RWD has impacted their design process.

For the past couple of years, most of the sites we have built at Beaconfire have been responsive.  From our perspective, the reason is simple: The end results are more usable for more people and, as your process evolves and you adjust to designing sites in a responsive way, it just doesn’t make sense to do it any other way.

What if you can’t pull up stakes and do an entire RWD process from soup to nuts? What if you just redesigned your organization’s website last year and you really need it to work better on handheld devices now, but can’t redesign the whole site for another year or two? 

A “Responsive Retrofit” can be a viable option depending on the site.  It is entirely possible that you do not need to completely redesign your site or go through an entire separate creative process. By not creating wireframes or designs and, instead, simply starting with the HTML and CSS that you have now, we add responsive CSS and can, in many cases, make the layouts work better on smaller screens. Results may vary and you may be limited in how much of the site you can make responsive.  The important thing is to be able to evaluate the site up front and have a clear idea of how responsive it can be made, and what tradeoffs there may be.

Be forewarned: In a true responsive design you have plans that minimize the amount of markup, CSS, JS, and images that you deliver to devices.  The retrofit approach very commonly increases the number of files delivered to the device and the overall “weight” of the page, and should only be considered if your site already performs well in terms of speed.

Here are six key things to look for when evaluating an existing static website for a retrofit:

  • How well was the site coded?  Is there nice clean HTML and few (if any) tables?
  • Is the order of blocks already correct for what you want to accomplish in a layout where everything will stack in a single column?
  • Are there classes and IDs for you to leverage without the need for overly complex CSS selectors?
  • Does the site contain consistently sized images that will all work well at 300-400 pixels wide (small images don’t size up well, huge images are, well, huge)?
  • Are all your page layouts consistent and few?  Too much variety will make for more work.
  • Is the navigation simple, and does getting to deep content not *require* the use of navigation?  If so, do your mobile users need access to that content?

Of all of these things, the hardest nut to crack is almost certainly going to be your navigation. This is especially if you have a really deep architecture.  But generally, if you like the answers to those six questions, your site may very well be a candidate for a retrofit.


About the author:

Tim Arnold is a Functional Consultant and Front End Developer at Beaconfire, where he has honed his skills consulting on custom Web application development, content management implementations, interface design, usability, and accessibility projects. Tim’s expertise includes HTML5, CSS3, and JavaScript with which he builds templates and pages for systems such as Convio, Drupal, eZ Publish, Sitecore, and WordPress, and he is Beaconfire’s in-house expert on mobile web and Salsa! He has worked with numerous organizations and companies, including most recently at Beaconfire: The Nature Conservancy, AdCouncil, AFL-CIO, American Federation of Teachers, American Legacy Foundation, Annie E. Casey Foundation, Feeding America, Charles S. Mott Foundation, Skillman Foundation, and the Union of Concerned Scientists.

Like what you're reading?
Sign up to receive the latest articles and updates on nonprofit tech from NTEN and its community of experts.

Subscribe

Tim Arnold
A Functional Consultant at Beaconfire Consulting in Arlington, Virginia, Tim brings over a decade of experience to bear in helping nonprofits design and build Web sites that meet strict standards for usability, accessibility, and browser support. He has honed his skills consulting on custom Web application development, content management implementations, interface design, usability and accessibility projects, and mobile solutions for numerous organizations and companies, including AdCouncil, American Federation of Teachers, American Legacy Foundation, Feeding America, Charles S. Mott Foundation, Skillman Foundation and Wildlife Conservation Society. Tim’s interface engineering expertise includes HTML, CSS and browser-side scripting within templates and pages for systems such as Blackbaud, Convio, eZ Publish, HotBanana, Sitecore, RedDot, and WordPress, just to name a few.