If you work in or with the web and make even a modicum of effort to remain buzzword compliant, you're probably uber-familiar with the term "responsive web design." Perhaps you've also heard of "adaptive web design" and "progressive enhancement"? If you're like me, you may have found yourself wondering what exactly these words mean, what the differences are, and why everyone seems so giddy to use them in a sentence.
Let's start by acknowledging that the web, by its very nature, began as a rather "responsive" thing. In 1991, HTML itself provided a way to make documents accessible for the masses across a "word wide web." By 1996 we had Cascading Style Sheets furthering this idea of the separation of content from its presentation. By 1998 CSS2 came along and we even had "media types," making the web even MORE "responsive" to varying contexts and uses. Finally, in 2001 Jeffrey Zeldman's To Hell with Bad Browsers
article on A List Apart put some real energy behind designing in this way, forcing browser makers to begin making browsers that more fully adopt these standards. By this point you would think that the web would have reached its pinnacle, and all websites would have embodied some glorious syndication of clean and sensibly marked-up content, digestable in an infinite number of ways by a growing number of devices. But wait ...
Designers Are Control Freaks
As the web evolved into something that more and more businesses were using, more and more designers could get paid to work on making websites instead of brochures, annual reports, business cards and the like (not that there's anything wrong with those). Print designers (myself included) began diving into this new medium and trying desperately to bend it to their will, manufacturing an ever-more controlled and fixed medium like we were accustomed to designing for. Designers like myself, who began crafting websites without a clear understanding of the medium, created painfully horrible mark-up full of tables and spacer gifs in an attempt to achieve the printed-page-looking layouts we dreamed up. By the time we figured out CSS, the goals were still the same. Designers would brag about their ability to achieve "pixel perfection" via CSS, essentially boasting about their ability to make a fluid and flexible medium exactly match one that is completely fixed. This mindset within the design community may not have changed all that much yet. Even our popular present-day community tools like dribbble are designed for showing off a fixed medium snapshot of our work (perhaps someone will create vibbbble, the video dribbble?). But enough designer bashing (I'm allowed, I'm a designer).
Tiny Screens & Slow Internet to the Rescue!
As usual, we go where the money is, and as smart phones moved from being pocket-weight for the cool kids to what many businesses wanted to invest their dollars in, designers came along for the ride. However, in a world filled with websites designed and developed with increasingly ubiquitous high-speed broadband in mind, we now began dealing with 3g or even Edge Network (gag) and worse internet speeds on tiny displays. So we did what any good designers would do. We developed native apps where we could tightly control the visuals and we created wholly separate mobile versions of sites that limited users to only the tasks we imagined them doing on their smart phones. We were the beneficent dictators of the mobile web. And we had it all covered. Desktop displays ... check. Tiny mobile device displays ... check. After all, who would ever be using the internet on something in between
the size of say a smart phone and a desktop computer display?
And then there were iPads
I was going to title this "And then there were tablets," but let's face it, every other tablet is essentially trying to be an iPad at this point. But I digress. The truth is that there are a large number of devices with screen sizes in between that of a smart phone and a desktop computer. Desktop computer displays keep getting larger as well, thereby increasing the discrepancy between, and array of possible sizes. Oh, what to do?
A responsive response
I believe (readers can correct me if I'm wrong) that Ethan Marcotte essentially coined the phrase "responsive web design" with his article by that name
in A List Apart back in May of 2010. In his article, Ethan laid out both the problem that is facing us as web designers as well as a very specific method for solving it. He called this method "responsive web design," and it included three specific tools.
- Fluid Grids
- Flexible Images
- Media Queries
Ethan then one-upped himself by writing a fantastic book on the subject with the creative title of Responsive Web Design
. In his book he laid out in great detail a process and methods for achieving responsive web design. From that point forward, Ethan's three-pronged approach became the official meaning behind the term responsive web design.
I have to admit, when I first heard people referring to responsive web design I'd not yet read Ethan's article (I know, shame on me) and I assumed responsive web design was … well … web design that was responsive. Responsive to what? I assumed varying display sizes, browsers, etc. I also assumed that HOW these web designs responded to said contextual variants was up to the whim of each designer and that it certainly wouldn't matter whether a site was built upon a flexible grid or dynamically shifted layouts on a fluid grid as a screen resizes. Boy was I wrong. We web designers sure do love our semantics, and apparently simply responding by changing layouts rather than via a fluid grid with flexible images is not responsive web design at all. Apparently, it's called "adaptive web design" when your web site responds to these varying contexts without
fluid grids and flexible images.
An adaptive response
You may not have noticed, but the internet seems to have a LOT of websites and applications that are already built. For many designers and developers working on and managing these websites, the idea of starting from the ground up to rebuild their output mark-up, images, and CSS is daunting at best. In many of these cases, it is preferable to keep the current design built for desktop displays and simply "adapt" it for varying contexts. For a peek into a real-world example of why you might "adapt" your design, read Dan Cederholm's recent write-up about adapting the dribbble design
. It explains this very scenario of dealing with a complex existing site with lots of users and lacking the resources to start from the ground up "responsively." This alternate (perhaps more limited scope) approach of adapting a design to varying contexts is what I then came to understand "adaptive web design" to mean.
Then Aaron Gustafson came out with a book with the moniker Adaptive Web Design
existing web designs, or designing for controlled adaptation as opposed to a truly fluid and flexible "responsive" design.
But, isn't it all so responsive?
Ok, so why can't the word "responsive" just mean what it always does? Why can't it apply to any design approach that aims to be, well ... responsive? Because I'm prone to getting hung up on words, I've been asking that question ever since I first came across Ethan Marcotte's article and book. Thankfully, last month, Jeffrey Zeldman asked that very question on his blog
, and I feel like that gave me permission to begin using the term in that way from now on (queue the sighs of relief). Zeldman summed it up very well. "Our understanding of 'responsive design' should be broadened to cover any approach that delivers elegant visual experiences regardless of the size of the user’s display and the limitations or capabilities of the device."
One more thing: Progressive Enhancement
If you've been hearing about responsive web design, adaptive web design or progressive enhancement (or if you've not heard of them) and have wondered what it all really means, hopefully I've begun to take the wrapper off for you a bit. If you wish to become a total guru on all things responsive, adaptive and otherwise, here's a quick list of reading material to get you on your way.
Hey, wait a minute …
You may be asking yourself, if this guy knows so much about all this responsive adaptive mumbo jumbo, how come this site doesn't seem to be responsive? Patience my friend, patience :-)