Breaking Dev: Pragmatic Responsive Design

by September 12, 2011

In her Pragmatic Responsive Design presentation at Breaking Development in Nashville TN, Stephanie Rieger walked through a detailed overview of building an adaptive Web experience for hundreds of devices. Here are my notes from her talk:

  • Case Study: Nokia promo page to prompt people to update their browser.
  • Experimented with responsive design to support global audience and wide range of target devices. Wanted to target 70+ devices to get people to upgrade their browser. From really high-end Symbian phones to low end Series 40 phones. Left old legacy and XHTML-MP browsers off the support list. Too low-end.
  • Most Nokia users on S40 feature phones use Opera Mini.

Design Process

  • Designing pixel perfect mock-ups makes it impossible to then think responsively. You actually need to throw previous processes and tools away.
  • Actual process moved from sketches to basic visual mockups to live HTML almost immediately. Then quick iteration between small visual mock-ups and live code.
  • You have to count on things degrading, as some properties will not be available across all browsers.
  • From the start of the design process you need to have actual content (in this case, copy).
  • If it’s layout prototype it on real devices to clarify changes in context and impact of capabilities and viewport.
  • If it’s visual, mock-it up but still prototype it to test performance, impact of native fonts and em values, viewport conditions.
  • There were too many pain points to mention. Mental models are getting in our way. We have lots of counterproductive behaviors we need to unlearn. Our clients still presume and expect we can control too much.
  • Creating elaborate workarounds for edge case screen sizes
  • Agonizing over small differences in rendering
  • Creating elaborate reference lists of data assuming you can design for each device.

The CSS Strategy

  • Mobile First: design for (the simplest) mobile browser first.
  • The absence of a media query is your first media query. It defines an initial breakpoint. Begin with a lightweight default: flexible with styles for fonts, navigation, and content.
  • Embrace the cascade: don’t merely swap style sheets let them cascade. This creates a more nimble style sheet that can reduce jumpiness during device re-orientation. Re-orientation is the primary user action that changes styles.
  • Each successive style sheet augments the previous design with the style changes that are needed to enhance the layout.
  • Major and minor breakpoints: major = big layout changes, minor = small adjustments within a layout. Minor breakpoints are covered within each major style sheet (media queries within media queries).
  • While an extra style sheet adds a few additional http requests, its not that big a deal relative to other performance hogs. For example, a Facebook Like button has 84KB and than 10 http requests. 3rd party requests for widgets, ads, analytics, utilities, etc. are all designed for the desktop and not optimized for mobile.
  • If a few well-chosen http requests enable you to improve your experience then go for it.
  • There is no perfect set of breakpoints. It depends on your project, audience, their devices, and your goals.
  • But major breakpoints typically cover 320 (iPhone, Android, Blackberry), 720 (tablet range), 1024 (desktops), bigger sizes for TVs. Within each, you may have minor breakpoints.
  • Does it make sense to create breakpoints based on the devices you are targeting or for a continuous scaling behavior? It doesn’t make sense to have a breakpoint for every device –you’ll have too many.
  • Review your existing traffic logs and focus on the devices already accessing your site.
  • Once you get below 800 pixels all that matters is how it looks on real devices. Desktop resizing tools fail to include browser emulators.
  • Minor adjustments (within a breakpoint range) can be percentage adjustments, font sizes, and different background image placement techniques.
  • Designing breakpoints also reveals another important issue. We cannot presume that screen size maps to browser capabilities. A phone with a different browser is pretty much a different phone.
  • If you are using responsive Web design, you can actually be talking to vastly different browsers.
  • Responsive design will only get you halfway. Always pair responsive design with a feature detection and adaptation strategy.
  • Step 1: media queries detect screen size and serve “size appropriate” style sheets and behaviors. Step 2: feature detection clarifies actual capabilities of the browser.
  • The more accurate information you can detect, the more intelligently detect. It’s not just client solutions. You can also use device databases, user agent strings, and your own tacit knowledge.

Responsive Images

  • Serve the most appropriate image to each device. A lot of approaches use the client to swap out and adjust images. But you can use a combination of server and client instead.
  • Most responsive images design mobile first and include images for mobile browsers then on more advanced browsers, detect the screen size using JavaScript, rewrite/adapt the image tag, then load an appropriate larger image
  • Most sites start with something big, and find ways to squish it down or remove them. This puts the burden of screen size detection, resizing and/or loading of new images on the smallest devices.
  • Image replacement techniques can impose a heavy burden on the client: detect screen size, spider the DOM, adapt the markup, request a new image, repaint or reflow as needed. This can make things hard for clients.
  • Optimize front-end first. 80% of user response time is on the client. With mobile it is closer to 100%. So anything you can do to take the burden off the client is good.
  • Heavy lifting should happen on the server. Query the user string, device database, etc. This delivers only what is needed to the client.
  • Use onResize event to adjust for orientation since support for onOrientation change on some browsers is not well supported.
  • One Web is a great ideal but adding or removing content based on contextual instructions can really enhance the experience in some cases. Like browser specific instructions.
  • Pain point: reliance on cookies. What happens when they are disabled or outlawed?
  • Pain point: how do you decide what the defaults are when you fail to detect devices on the server? This remains an open question.
  • What about unknown devices not yet in a device database?
  • 80% of traffic seems to come from 20% of devices. Whatever is left is still known devices. The unknown device list tends to be pretty small.
  • User agent strings can be incredibly useful but understand their limitations.

Responsive Workflow

  • Used to design with one canvas to create image assets. Now better off using a bigger canvas to see multiple versions of an image in one file.
  • Helps eliminate alignment errors, continuity issues, and maintain thematic consistency.
  • This is still not flexible enough as it is a very manual process.

Embrace Opportunities

  • Used a server side adaption to change the doctype from HTML5 to XHTML MP and CSS MP in order to be accessible to another 80-100 older feature phones.
  • Be pragmatic. Perform a cost-benefit analysis for every technique you use. Old doesn’t mean bad and new doesn’t mean good. If a technique does more good than bad... its worth using.
  • Review your traffic logs and determine what mobile devices are accessing your site today
  • Test your site on those devices and determine where the experience breaks down
  • Develop a plan to address common issues.