Responsive vs Adaptive Web Design: Better Together
Responsive web design (RWD), the ability for your web application to “respond” to the size of the view port (traditional screen size vs mobile screen size) is common place and practice today. Responsive design leverages client side, front end UI frameworks to hide, show, stack, shrink and grow elements on the screen in a way that is appropriate for the size of the device’s screen. In essence, it is many user interfaces in a single code base.
Adaptive web design (AWD), a (seemingly) alternative approach to RWD is a server side capability to respond to the client with completely unique templates / markup for a given device type (amongst other facets.) Adaptive design, while extremely powerful is somewhat less common in part because it relies on a server and is thus a less general technology. It’s also less prevalent in part because, for a large class of problems, RWD is “enough” to get the job done. However, as complexity and sophistication of requirements mount, adaptive design starts to show clear advantages over a purely responsive approach.
Responsive design and adaptive design are often thought of as an either/or architectural choice. There is clear overlap in the problems they address and each approach has clear strengths and weaknesses over one-another. Let’s take a quick look at a side by side comparison:
Responsive Design: Leverages server agnostic front end frameworks (eg. Twitter Bootstrap) to render a appropriate content flow for the given screen size.
Adaptive Design: Leverages back-end server templates (e.g. Crafter CMS) to render distinct markup for the device and context requesting the application.
- Mainstream approach with many frameworks that can be applied to any backend technology.
- Single code base
- Truly unique markup can be delivered based on any kind of context (not just screen size.) This means it’s much easier to deliver contextual functionality to your users. Example: A retail store .com site that has a traditional marketing website at mystore.com but once it’s detected that a user is inside a physical store location, it gives them a personalized in-store assistance to enhance their shopping experience.
- Performance. With AWD you send only the data you need for the experience you are delivering. On slower, mobile networks that can make a big difference.
- Single code base. The more variations you want to support, the more code and complexity there is in that single code base. This can get out of control.
- Performance can be an issue: RWD sends all of the code for all variations to every consumer whether or not they will see it in their flow or not. If the amount of code is significant, this can lead to a performance hit on slower/mobile networks.
- It’s difficult (although not impossible) to address different contexts beyond screen size with Responsive design. RWD was really intended to different screen sizes (view ports.) Stretching its role beyond that takes the technology out of its wheelhouse.
- You need a server backend to support AWD.
- Instead of a single UI design and template code base, you potentially have many. If you don’t manage and factor the code properly it will be more difficult to maintain.
- Provides a usable experience on any screen size.
- Provides a usable experience on any screen size.
- Provide faster experiences for your users.
- Allows you to truly contextualize the experience. Device type/class/screen size is really just the tip of the iceberg. Once the server is involved any type of contextual data (location, previous use, time of day, etc) can be used to deliver unique and relevant experience/features to the user. That can be huge.
- If requirements go beyond screen size, RWD may not be the appropriate solution.
- If the number of variations is too high performance and code complexity may be an issue.
- Managing unique templates is a heavier approach that requires server technology and the skills to go along with it.
While RWD and AWD are most commonly looked at as competitive approaches, the simple fact is that they are not. These two approaches are in fact mutually exclusive with another and can be combined to acquire the benefits of both.
Responsive design is front end technology. Adaptive design is backend technology. Combine them.
Consider leveraging Adaptive design to drive truly unique and contextual markup to the user for what they are doing, on the device of their choice at that moment. Allow the front end to leverage Responsive frameworks to make sure those experiences flow nicely on a given device. For performance and code maintainability, as your RWD code grows in complexity and size, consider breaking it down in to smaller code bases that can be individually delivered to a device by RWD (the server.)
A simple example of this is to have AWD templates for Small, Medium and Large screens. Each with their own unique features and markup. When it comes to the specifics like an iPhone vs a Galaxy smart phone (both considered small), RWD steps in to make the minor adjustments required to provide a perfect fit for the given device type. This makes the code more maintainable and more importantly it makes the user’s experience much more zippy.
Russ Danner is VP Products at Crafter Software and is responsible for product management, product development and support, and client and partner success. Russ brings over 20 years of software architecture, design, and implementation experience. Prior to Crafter Software, Russ was Web Experience Management Practice Director at Rivet Logic and project lead for the open source Crafter CMS project. Russ has also been active in the Alfresco community since 2005 as a community leader, contributor, trainer, speaker and user group organizer.