Responsive vs Adaptive Web Design: Better Together
Responsive vs Adaptive Web Design: Better Together
When it comes to choosing between adaptive web design and response web design, why choose at all? They make a great match.
Join the DZone community and get the full member experience.Join For Free
Learn how Crafter’s Git-based content management system is reinventing modern digital experiences.
Responsive web design (RWD), the ability for your web application to “respond” to the size of the viewport (traditional screen size vs mobile screen size) is a commonplace 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.
Leverages server agnostic front-end frameworks (eg. Twitter Bootstrap) to render an appropriate content flow for the given screen size.
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 site 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 assistant 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.
- A 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 for different screen sizes (viewports). 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.
- 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 experiences/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 inclusive with another and can be combined to acquire the benefits of both.
Responsive design is a front-end technology. Adaptive design is a 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 into 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 smartphone (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 zippier.
Published at DZone with permission of Russ Danner , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.