On Adaptive vs. Responsive Web Design

In the past few months, I’ve spent an inordinate amount of time discussing the differences between the “adaptive” and “responsive” web design philosophies. Don’t get me wrong, I love having these discussions, but I felt the need to set the record straight: these two philosophies are not at odds, despite numerous blog posts and tweets to the contrary.

Responsive web design,” as coined by Ethan Marcotte, means “fluid grids, fluid images/media & media queries.” “Adaptive web design,” as I use it, is about creating interfaces that adapt to the user’s capabilities (in terms of both form and function). To me, “adaptive web design” is just another term for “progressive enhancement” of which responsive web design can (an often should) be an integral part, but is a more holistic approach to web design in that it also takes into account varying levels of markup, CSS, JavaScript and assistive technology support.

For the record, I do think it’s important to draw a distinction between “adaptive web design” and “adaptive layouts” because “adaptive layouts” implies only the use of media queries, which may not be done in a progressively enhanced way. Adaptive layouts achieved in a mobile-first manner, however, are very likely progressive enhancement and, thereby, a means of “adaptive web design.

Like it? Share it

Share on LinkedIn

Share on Google Plus

Comments

  1. I also regularly have to clarify that “responsive” is a subset of “adaptive”.  I usually have to give a few examples to help people understand.

    Can this device access my location? If so, inject a “Use Current Location” button onto the site in addition to the basic store-finder form.

    Does this device understand touch events? If so, make this image carousel swipeable in addition to the “previous” and “next” buttons.

    Does the browser support HTML5 canvas? If so, replace this static image with a canvas element.

    These are all concrete examples of how experiences can adapt based on the capabilities of the device/browser. The important takeaway is that we shouldn’t assume support for these features by default and instead progressively enhance up to the optimal experience. Same thing goes with responsive layouts. Don’t assume large screen (which also assumes strong connection) by default, and instead build base styles that enhance up to larger screens.  Removing assumptions helps us design for constraints and provides better support for more browsers/devices.

  2. Well put, Brad. Thanks for adding your 2¢!

    • Aaron Gustafson
    • | #
  3. Completely true. But I also feel there is this huge trend of getting caught up in semantics these days. I don’t really like the idea that Ethan Marcotte is now credited with coining the responsive design tag. Good developers have always been optimizing for the lowest denominator. I.E. IE (wow great unintentional pun by me… ).

  4. I think that the best way to think of the Marcotte brand of responsive design is that it achieves resolution independence (which is better than nothing) but not full adaptation. Zeldman (Ethan’s publisher) later clarified their stance on responsive design to encompass *any* technique used to achieve this end, not just fluid grids/media queries etc.

    Note that almost all of the Alexa top sites use server-side device detection to deliver different markup depending on device.

    We have a survey of all adaptation techniques at http://mobiforge.com/starting/story/mobile-web-content-adaptation-techniques

  5. Resolution independence — that’s a great term!

    It may not seem completely fair that Ethan gets so much credit for the concept of responsive design, but I can attest to the value of my first encounter with the idea in 2010 via his talk at AEA. His presentation changed how I do my work and, a year later, substantially changed my career.

    Also, it’s about a lot more than designing to the lowest common denominator.