Responsive Web Design vs. Adaptive Web Design… Which one is for me?
The answer is… both! There seems to still be some confusion throughout the industry that Responsive Web Design and Adaptive Web Design are mutually exclusive. In fact, that couldn’t be further from the truth. Aaron Gustafason does a pretty good job explaining the differences on his blog, but to summarize, Adaptive Web Design embodies the philosophy that web interfaces should adapt to the user’s capabilities and is really synonymous with Progressive Enhancement (which is subtly different from Graceful Degradation by the way). Responsive Web Design, on the other hand, is the term used to describe the tactic of using fluid grids, fluid images, and media queries to achieve a layout that responds to all form factors on the web. You can even think of Responsive Web Design as a subset of Adaptive Web Design. At Zoosk, we used these basic principles and capability based thinking to build a new platform that we feel will better support the ever changing landscape of web clients coming online everyday.
In the beginning…
At Zoosk, like all modern internet companies, we support an enormous array of devices, form factors, browsers, and operating systems. Initially, during our early startup days and with very limited resources, we focused solely on desktop browsers. When the mobile explosion began, we decided like most others, to start optimizing for smartphones. Those were the actual devices, but when you think about the different capabilities we cared about, there were two that came to the top.
Those two capabilities were:
- Touch Enabled – Using a finger as the main form of input.
- Mobile Device – In this context, we mean a mobile phone, tablet, or PDA, not a laptop or desktop.
At the time, that meant essentially smartphones then tablets. To achieve this, like most companies, we built a completely separate site which was optimized around these two capabilities; t.zoosk.com was launched which with feature parity of www.zoosk.com.
t.zoosk.com uses all the best practices to serve an optimal experience to our smartphone/tablet users. We inline statics to decrease the effects of latency, use smaller sized images, and have finger-friendly designs. One of the obvious downsides to spinning up another platform and team is that to achieve feature parity now, every new feature is required to be implemented by two teams instead of just one. As the company started to scale and mobile first designs and techniques started moving to the forefront of the industry, we began to notice deficiencies in how we were building our web applications and organizing work. We wondered if we could do better.
That being said, shifting to a mobile first ideology requires buy-in from the entire company, and rewriting our main single page app (search, carousel, messaging, and etc.) responsively didn’t seem like a logical starting point for us. It would have carried significant risk and opportunity cost, so we decided to build a different platform to handle only brand new experiences for the proof of concept. The platform Vulcan (the father of Cupid, our first Javascript platform) was born.
Enter Vulcan…
At Zoosk, for both www.zoosk.com and t.zoosk.com, we’ve invested significantly in two main client-side technologies, AngularJS and Google Closure Tools. You can read more about the specifics of our homegrown architecture in a great overview from from one of our web devs, Craig Akimoto. Vulcan is also based on those technologies and was built around the AWD (Adaptive Web Design) mantra. This required a shift in thinking, albeit a subtle one, to stop thinking about browser support and start thinking about capability support. As I mentioned in the introduction, once you start to think in terms of capabilities instead of browsers, it becomes much less complex to think about adding layers (progressive enhancement) of functionality based on those capabilities.
At the lowest level AWD prioritizes content, and ideally, even a browser without Javascript should get a functional site which would just be HTML/CSS. If HTML/CSS isn’t supported, then just text. Since only a tiny percentage of our users don’t have Javascript/HTML/CSS enabled, we made the conscious decision to make this our baseline capability. From there, we use WURFL on the server, to be our source of truth for a device’s list of capabilities, and progressively enhance based on which of those capabilities we support.
That sounds great, but let’s look at an example. If you head over to www.zoosk.com/safety on a desktop browser, you’ll see your run of the mill fully responsive web page. Feel free to play with the window size, and watch the page change as the form factor changes. If you view the source, you’ll see standard link tags for js, css, and images.
This is great for the browser as latency is typically less on desktop browsers since connections are generally more stable. This also allows us to take advantage of the browser cache once files have been loaded. If you head over to the same URI www.zoosk.com/safety (yep, no more device redirect logic needed) on your mobile device (or use the chrome inspector to emulate a mobile device), you’ll notice the page looks great on your phone as well. The kicker is that since we detected the mobile device capability, we do a few things differently now. For example, if you view the source, you’ll notice the js, css, and some images are now inlined!
| <style type="text/css">. | |
| stack-of-papers:after{-moz-border-radius:0 0 3px 3px;-webkit-border-radius:0 0 3px 3px;- | |
| o-border-radius:0 0 3px 3px;-ms-border-radius:0 0 3px 3px;-khtml-border-radius:0 0 3px 3px;bo rd | |
| inset-blue-background{background:#e7ebef;-moz-box-shadow:inset 0 2px 2px rgba(0,0,0,0.2);- | |
| ... | |
| </style> | |
| <script type="text/javascript"> | |
| function z_a(a){throw a;}var z_b=void 0,z_c=!0,z_d=null,z_e=!1;fun | |
| ction z_aa(a){return function(b){this[a]=b}}function z_f(a){return function(){return this[a]}}var z | |
| _,z_ba=z_ba||{},z_g=this;function z_ca(a){for(var a=a.split("."),b=z_g,c;c=a.shift();)if( | |
| ... | |
| </script> |
Keep in mind, this could be any mobile device (wearables? google glass? watches?), and it’s not just for smartphones and tablets.
Another interesting example is the language selector at the bottom of the page. If your device is touch enabled, we use the HTML <select> element since most touch devices give preferential treatment here, and you’ll see the native option selector.
If you’re not touch enabled, we trigger a popover for language selection. Again, this is all based on capabilities instead of browser or device type.
In closing…
As the number of new devices that are connecting to the web everyday increases, our goal at Zoosk is to take advantage of individual capabilities to provide the most delightful experiences possible for our users. Some of the future enhancements and capabilities for Vulcan would be:
- Retina Resolution Enabled – Enhance to serve retina quality images for these devices
- Various Input Capabilities – Some of the capabilities beginning to get more traction are remote control inputs for instance.
- Touch Enabled – Tooltips are another problem we haven’t had to tackle yet, but what do you do for tooltip support in the touch enabled context?
References
- http://blog.easy-designs.net/archives/on-adaptive-vs-responsive-web-design/ – Aaron Gustafson on Adaptive and Responsive Web Design
- http://easy-readers.net/books/adaptive-web-design/ – Aaron’s book on the topic of Adaptive Web Design.
- https://about.zoosk.com/en/engineering-blog/integrating-angularjs-with-a-large-google-closure-codebase/ – Zoosk’s single page web app architectural overview
- http://wurfl.sourceforge.net/ – Device Capability Detection
- https://developer.chrome.com/devtools/docs/device-mode – Device emulation using Chrome
