In less than 18 months, mStoner went from never having done a responsive site (a site that adjusts to display optimally on all devices) to having nearly 100% of our sites be responsive. I don’t think we’re alone in this; this turn of events is probably common to other shops engaged in web work. The increasing demand to deliver content to a multitude of devices has driven a need to change how we practice web design. It’s been a period of rapid learning and adjusting how we prototype, how we design, and how we develop. This post is a brief synopsis of the most important lessons I’ve learned (so far).
Content and strategy still come first.
Responsive web design is a set of design and development practices. Underlying both design and development, the need is still similar to the original challenges posed by web development: how do you deliver the right content to your audiences? Addressing strategy successfully is still the first step in deploying successful tactics.
Respecting the foundational ideas of responsive web design means providing a better experience across devices.
In the foundational book on responsive design, Ethan Marcotte articulates that fluid grids, flexible images, and media queries (code that changes CSS styles based on browser width) are all criteria for responsive design. We underscore these fundamentals because all three techniques were identified as foundational ways to provide an optimal experience based on the width of each visitor’s browser. As responsive design has gained popularity, you can find many examples of partially responsive sites that don’t cover these three fundamentals well—for example, sites that aren’t fluid between breakpoints. If you want the end product to be great, you have to honor the core fundamentals.
Performance is critical.
NBC reported on research showing that a majority of mobile visitors will only allow a site to load for about five seconds—any longer and the average visitor moves on to do something else. We agree that responsive development practices need to be tailored to deliver content as quickly as possible, particularly to mobile devices. To optimize our code, our development team (with our responsive development efforts being spearheaded by Jim Johnson) is concentrating on a variety of techniques that involve compression (making things smaller), consolidation (reducing page requests and making code as efficient as possible), code structure (ordering or delaying the load of elements in a sensible order), and custom content (changing page elements based on media queries). By optimizing the code, we help our clients deliver sites that load quickly. If you’re looking for more on these topics, responsive gurus Dave Olsen and Erik Runyon both maintain blogs focused on web performance.
Mobile is different, so the mobile breakpoint needs special attention.
Responsive design offers opportunities to rearrange content without building custom mobile sites or applications, but we have discovered the mobile view requires extra attention. Author and speaker Luke Wroblewski outlines the increasing importance of mobile devices used to access the web, including how mobile devices are used and how usability conventions change in a mobile context. Our own experiences with mobile usability testing have confirmed that using less than a third of standard desktop real estate to present content radically alters how people interact with sites. To assist with mobile usability, we are now constructing mobile wireframes, prototypes, or full mobile comps (or some combination of those deliverables) so our clients can better understand how page elements will change for mobile visitors. We’ve also begun folding in mobile-specific usability tests to better understand how visitors interact with the site in a mobile context.
Patterns are a helpful way to find responsive, usable page elements.
The fewer components a page has, the easier it is to build responsively. The issue we’ve come across in higher education is that many of our clients need pages that include many different components. In other words, we aren’t just addressing how basic page elements such as navigation are handled across devices; we’re also solving for the little things like multi-column text, tab structures, and tabular data. Considering patterns (what others have built) for page components is a way to avoid rethinking the wheel or creating pages that are mostly responsive but contain unusable page elements. To help with this, we refer to resources such as author and speaker Brad Frost’s pattern library.
Don’t leave planning out of your process.
I mentioned wireframes, prototypes, and comps above. These are all planning elements. What I’ve discovered is that trying to leapfrog planning usually results in one person (often a developer) being asked to make critical content or structure decisions as an afterthought. I don’t think there is necessarily a hands-down best approach to planning, but my advice to anyone about to engage in a responsive design process is to make sure you include some kind of prototyping.