The number of devices, platforms, and browsers that support web content are growing daily. This presents challenges for both engineers and designers when trying to create a usable website. One approach for accommodating these challenges is responsive web design: that is, a fluid design that adapts to any device, regardless of screen size.
The main idea of responsive web design is that on loading, the page will detect the width of the screen or window and will then size and deliver content accordingly. This technique is one of the most talked-about up-and-coming methods for developing websites that are more mobile-friendly, making it something that a number of us within the company were eager to try. When we finally got the green light to do a responsive design for one of our clients, we dove right in. Some key technical concerns that we needed to consider right off the bat:
- At what key screen sizes should the design reconfigure?
- How do we make this cross-browser compliant?
- Which devices do we target?
- Do we limit the site functionality offered per device?
Selecting Target Screen Sizes & Devices
We settled on three key sizes to optimize the experience: small (less than 625 pixels), medium (less then 810 pixels), and large (810 – 990 pixels). We also decided that the smallest size targeted would be 320, which is the smallest of the standard widths on iPhones and iPods (touch).
While we were specifically targeting Android devices (mobile and tablet) and iOS devices (iPhones, iPad, and iPods) for this site, all development followed web standards and renders properly on any standards-compliant browser.
Handling Cross-Browser Compatibility
To detect the screen size and deliver content accordingly, we used a CSS3 feature called media queries. The only downside to using media queries is the lack of support in older versions of every developer’s favorite browser: Internet Explorer (IE)—as is the case with many CSS3 features, media queries aren’t supported in IE 8 and below.
The way around this: respond.js. It’s a lightweight (~1KB) JavaScript library that detects whether a browser supports CSS3 media queries and applies the rules to browsers that don’t natively understand them.
Developing a Cross-Device, Cross-Screen Size Approach
Regardless of device or screen size, we implemented the following:
- In order to keep file size small and download speeds quick, CSS and JavaScript got minified and combined into a single download each.
- Images were optimized to be as small as possible, which meant eliminating unnecessary colors from pngs, choosing the right file formats (using jpegs when possible, to avoid large transparent pngs), and then finally compressing all images by running them through an online image compressor. We chose to use PunyPNG, as it generated the smallest file sizes.
- To keep things truly “responsive,” percentages were used instead of pixels for widths, padding, and margins.
Optimizing by Omission
Social media functionality has become pretty standard on brand sites these days: “like” and “share” buttons are everywhere. It’s easy to overlook the fact that including these social buttons on a page usually means they will pull down a number of pretty heavy JavaScript files, and on mobile devices, the fewer files that need to be downloaded over the network, the better.
Based on this, and the fact that it’s much less likely for users to be logged into Facebook in a mobile browser, we chose to leave this particular piece of functionality out of the mobile experience. In order to turn this on and off based on a mobile vs. non-mobile device, we needed a way to know which devices accessing the site are considered “mobile.”
This device detection represents a slight departure from a “pure” responsive approach. But in balancing optimization with the business requirements, we ended up creating a bit of a hybrid approach. We chose to use a server-side detection library called “Foundation”. Foundation uses a regularly updated, central database of device specifications to identify where requests for the website are coming from. Based on whether foundation identifies a request as coming from a mobile device, we can determine whether to show or hide the social buttons.
Including Mobile-Specific Functionality
In addition to the basic guidelines mentioned above, we made several adjustments that only appear on mobile devices:
- Added a “back to top” button in the footer.
- Included a “swipe” javascript library for items that have next and previous functionality.
- Removed the dropdown-on-hover menu from the global navigation.
- Added padding around small links to make them more “touch” friendly.
- Created smaller images and used the server-side mobile detection to swap the image source from the full size version to the mobile size.
- Removed hover states from touch devices. This was done by implementing the touch detection provided in Modernizr.
Key Lessons Learned
Here are a few important insights to keep in mind for any responsive web design project:
- Keep the page designs simple. If it needs to scale, it’s not going to be pixel perfect.
- Collaborate closely with the designers and information architects – chances are the design and navigation will end up evolving during the actual implementation.
- When coding the templates, allow elements to maintain their natural document flow wherever possible. The less complicated the code, the easier it is to scale things properly.
- Give Yourself Extra Time! It WILL take longer to code than a standard interface. This process is a challenge for both engineers and designers, because you are, in essence, creating multiple templates within each template.
In the end, this was a very satisfying project, as the site can be viewed on any device (desktop, tablet, mobile phone) and looks equally great on all of them! In an ideal world, we would implement this everywhere, but realistically it has a time and place based on the needs and user base of the site.
