Back to Insights

Progressive enhancement and responsive web design — more takeaways from Breaking Development

As I mentioned in my last post, I attended the Breaking Development Conference last year and found some absolutely incredible takeaways related to designing for the mobile experience.

In this article I highlight some of the more technical takeaways from the conference on designing to support such initiatives as progressive enhancement and responsive web design.

Listed below are my five biggest takeaways for practically designing for mobile:

  1. Mockups and prototyping in parallel—an emerging process
  2. True progressive enhancement is possible, but it's not easy
  3. Major and minor responsive breakpoints can get out of hand very quickly
  4. You have to think about designing for responsive websites throughout the entire process.
  5. Responsive web design technique involving server-side cookies.

These topics are all inspired by the fantastic presentations at the conference and interesting conversations that came out of them and I encourage you to seek out the original presentations for more great content.

  1. Mockups and prototyping in parallel—an emerging process

    I enjoyed Stephanie Rieger's presentation on Pragmatic Responsive Design. Not only is she a fantastic speaker, but her depth of knowledge and expertise is vast. This particular presentation was a practical look on the work her company Yiibu completed for Nokia to introduce three new Web browsers for Nokia devices. They decided to create this site responsively, not only as a chance to build up their responsive chops, but also because Nokia has a wide array of devices at many different screen orientations. It's a very effective technique to handle a range of devices that could potentially access the site.

    Through this project they discovered a new, emerging process of introducing prototyping almost in parallel to the discovery process.

    They had three main rules in this emerging design process:

    1. If anything has been decided about layout, prototype it.
    2. If anything has to do with visual design, mock it up, but integrate those new sections back into the prototype to test performance and other practical requirements.
    3. If there's content available (as it was in their case), add it into the prototype as soon as possible.

    As we have seen in the responsive re-development of our own UE Done Right site, responsive sites benefit immeasurably from increased interplay between the designer and the UX developer throughout the design process. Stephanie couldn't stress enough that the sooner you can get your prototype working, the sooner you can test the native capabilities and differing viewports on your designs, on real devices, and tweak accordingly. In essence, the most important thing to test when designing for mobile is how it looks and how it performs on physical devices.

  2. True progressive enhancement is possible, but it's not easy

    iPhone view of Boston Globe siteScott Jehl from the Filament Group presented at the conference as well. Filament Group worked on The Boston Globe website, which was probably the first major large-scale website to be designed using responsive web design.

    The Boston Globe website was planned from the start for progressive enhancement. They wanted to "make it work everywhere?and work especially well in new browsers". To fully illustrate this, The Boston Globe website works on an old Newton MessagePad 2100! That is impressive!

    Both Yiibu's and Filament Group's approaches to progressive enhancement were fairly similar. They created a basic baseline of CSS and the cascade is embraced as much as possible when adding additional CSS files for more advanced browsers. In the case of The Boston Globe, they actually remove this basic CSS from the <head> using JavaScript as the basic changes for the simplest browser did not cascade well.

    Scott's closing remark was memorable:

    "We have the tools to build sites that are rich without being exclusive".

    This is as much a statement of fact, as it is motivational. We have what we need right now to implement responsive (and responsible) designs that are progressively enhanced to take advantage of the features of newer browsers. So go for it! It's not easy, but it's possible and very worthwhile.

  3. Major and minor responsive breakpoints can get out of hand very quickly

    The basis of responsive design is not and should not be to support particular devices. This is a trap that many people fall into when designing a responsive site—many times because of pressure from clients who own particular devices, or even from developers who own particular devices.

    The spirit of a responsively designed website is one that delivers a layout that scales well for the majority of devices that could access it. We cannot (and should hope not to) predict every device that could access our site, now or in the future. But we can deliver an interface that looks good (but not pixel perfect) on the vast majority of devices.

    Here are some tips that I gathered Stephanie and Brian's presentations on picking your major and minor breakpoints:

    • Major breakpoints should not be created with a device in mind; they should be created with a layout in mind. Covered here should be large layout changes like when to switch from a two column layout to a three column layout.
    • Minor breakpoints again should not be created with a device in mind; they should be logical tweaks to a major breakpoint to ensure that the display still looks natural. For example, at a minor breakpoint an image could switch from covering 25% of an area to 30% of an area.
    • A good responsive design consists of a comprehensive set of layouts that are meant to cover many different devices. Yiibu recommends application of the 80/20 rule and to avoid falling into the trap of creating breakpoints for every single device.
    • Pixel perfection for every possible device is unrealistic and expectations need to be set with clients that there will be differences in how it displays with different devices not only based on straight screen resolution, but the type of browser used as well. Browser chrome can further shrink the available area for the screen to view a website.
  4. You have to think about designing for responsive websites throughout the entire process

    The Boston Globe website is a poster child for responsive and responsible websites, but you have to think about designing for responsive websites throughout the entire process.

    Scott's presentation made the point: "Ok, it's responsive, but is it responsible?"

    Filament Group outlined four areas of responsibility that I believe are very important to keep in mind when designing any site, not only a responsive one:

    • Accessibility
      • There was constant focus on accessibility throughout their development process which included keyboard navigation and application of WAI-ARIA to ensure that the site is meaningful to screen readers and other accessibility tools.
    • Performance
      • Because mobile websites must run on phone networks in situations with unreliable network connectivity, performance becomes a very important issue. They used techniques such as lazy loading (if Web Parts are below the fold) and feature/capability specific CSS/JS file loading to ensure that each access of the site is only loading script/styles that are relevant.
    • Usability
      • Special focus on offline input form entry and ensuring to cover both touch and mouse events (for devices with buttons as well as touch) as well as having image rotators that respond to both click and touch events ensure that use of these controls are consistent to the devices that use them.
    • Sustainability
      • They produced a solution that was very well-designed from the start with sustainability in mind in order to ensure that the site can continue to be enhanced and improved without going back to the drawing board.
  5. Responsive web design technique involving server-side cookies

    Bryan Rieger's presentation on adaptation (check for it around slide 83) included a fantastic and comprehensive set of flowchart slides describing communication from the client to the server in delivering a responsive and feature-optimized site using server-side cookies.

    This technique essentially involves associating a profile cookie with each device and using a device atlas to retrieve more information about this device from the server side to determine and deliver appropriate feature specific assets (scripts, styles, images).

    Bryan also chats about starting and maintaining a tacit knowledge database to further add to the intelligence that can be used on the server side. I think this is a very important point that should not be overlooked.

    For example, perhaps a particular mobile browser supports a tap and drag action natively, but its particular implementation has been known to be very buggy in practice at this point in time. The device atlas might determine that the device supports this event, but your first-hand knowledge proves that the browser might as well not support it. The tacit knowledge database can serve as an override in order to provide the best experience to the user based on their method of access.