Everyone wants to be “mobile-friendly.” In Part One of this two part series, we examine two often confusing terms in web design and development: Adaptive and Responsive.
It’s common for these terms to be thrown-about interchangeably, but they don’t mean the same thing. Both drive at the same point: “How do we make our website accessible to every user on every device for a functional experience?” (Bonus points for fun surprises along the way.)
Adaptive vs. Responsive
It used to be so simple, right? Desktop and mobile, those were the chief concerns for any website. Out of this idea, adaptive design was born. We can serve a specific layout to only mobile users! Hooray!
Now, with phones the size of tablets and tablets the size of desktop displays, there’s so much to prepare for it can seem overwhelming. Oh, but wait! You haven’t thought about everything yet. Retina displays, 4k, 5k or even 8k TVs should be on the radar for any developer or designer.
It’s all about writing future-proof code, because really, what code shouldn’t be future proof?
To deal with the myriad of devices and screen sizes, responsive code is a way to serve the same general layout regardless of device, but enable the code to “respond” to media sizes, usually screen sizes.
There are plenty of ways to go “mobile-friendly” from a design and development standpoint. Time, hours and scope are always key components. With that in mind, let’s take a look at what adaptive and responsive actually mean, along with some pros and cons.
Adaptive is:
- Serving a different layout based on the user’s device (think of a “mobile version” with a mobile URL that was ubiquitous several years ago).
- Targeted towards specific devices, with code written to detect these devices before serving the appropriate layout.
- Often used as an add-on to the current website experience (e.g. “Let’s get a mobile version up!”).
- Able to be whipped-up and served without touching the original website code.
- Past-proof.
Responsive is:
- Serving a one layout that changes and responds to the user.
- Targeted towards any screen-size a user could be using, including those that haven’t been invented yet.
- Provides easy reading and navigation without panning, scrolling or resizing at any screen size.
- Changing your current website’s code (all future updates are in one place).
- Future-proof.
Which one should I choose?
Young padawan, the force is strong with you. It’d be stronger if you said, “Responsive is best, but adaptive is useful.”
Adaptive can be an extremely smart design choice – especially for a legacy website that needs a way to catch up to the mobile world. Every website owner in the world received an email from a CMS plugin provider or web design firm during “mobilegeddon” in 2014. Why? Adaptive is quick and easy.
The problem with adaptive is its limitation to what the code can target right now. If a new device sweeps the market in a year, it may be time to design a new layout to fit that screen size and detect that using code.
Suddenly the “quick-fix” has turned into a long-term project that needs constant updating, in multiple places (mobile layout, tablet layout, 4k layout, etc.)
In adaptive’s defense, serving a near pixel-perfect layout based on devices has its upside. You’ll know what the user is getting every time based on their device.
But…
Responsive is getting a website ready for it’s 2-5 year run (possibly longer) in production. Developing this way allows a website to know it can handle whatever is coming down the line now, rather than be scrambling to update when the time comes. It increases branding across devices too, knowing that new designs won’t have to be created when another device is trending with users.
When designing and developing for responsive, there are two ways to skin the cat: fluid or fixed. In Part Two of this series, we’ll examine the pros and cons of fluid vs. fixed layout design in a responsive project.
Remember, 20 lines of CSS could be the difference in a website that is ready for tomorrow’s user or a relic that Google won’t even label as “mobile-friendly”. Don’t be that website. Don’t write that code. Don’t get defriended by Google.