“I need more than a Responsive site, I need it to be Adaptive”. This is a thing I keep hearing. Except it is not a thing that exists. Every time I hear it I have an Inigo Moment™.
I understand the future is unevenly distributed and takes time for new concepts to get absorbed and a common language to emerge across a community of practice, so if at all possible, we should help move that along. Let’s break this down:
Responsive and Adaptive
Responsive — short for Responsive Web Design — is a term used to describe how we make a website’s content and its layout appear to appropriately fit the screen of a given device. As a front-end development technique, it uses media queries, fluid grids and flexible media to accomplish this. In short, you have one site and it appears to respond to whatever device you are using, conforming to its constraints, like magic.
Adaptive — short for Adaptive Content — is a term used to describe content authored with the intent to be distributed across multiple channels, media, products and/or interfaces. It presumes that content is authored once and its supporting workflow (between authoring, modeling, storage, distribution and publishing) exist in service of varied use (multiple end-points for consumption), not one specific use such as for a particular app for a specific platform alone.
So, if you follow, these things have nothing to do with each other. You could say that a whole site (or its layout, or its structure) could be Responsive (relative to a screen size), or not (AKA, fixed layout, 2002-called-and-wants-its-layout-back). And that content (whether text, images, audio or other kind of asset) could be Adaptive, or not (AKA, single-use, channel-specific, etc).
Why is this confusing?
1. Using shorthand terms when we lack shared language
As with many things, when we use shorthand language we assume prior knowledge of the person we are speaking to. This is useful because simple terms can represent complex concepts, allowing us to build on existing knowledge and have clearer in-depth, more sophisticated conversations.
I can tell you that a sauce is not smooth because the roux was not well done, or the flavor is flat because it lacked a mirepoix base, or that this polyfill is redundant since the new browser version was released, or the mixin is wrong because it uses inheritance when you just need a method. But if you don’t understand what mirepoix, roux, mixins or polyfills are — conceptually, not just the meaning of the word — the conversation doesn’t go very far, as we are interacting from different planes of understanding.
The danger is precisely in that assumption that you know what’s behind the shorthand term. This is not simply about vocabulary, it’s about assumptions of deeper understanding. If you are not comfortable with the concepts above, Adaptive versus Responsive sounds like a reasonable comparison because they fall in the realm of “things you have to consider when creating a website for use across platforms and devices”, even though one thing is not in opposition to the other. If you heard ‘Responsive Web Design versus Adaptive Content’ instead, it would already help raise a flag that this is not an apples to apples comparison giving you the opportunity to ask clarifying questions from the get-go.
2. Device is a common attribute we talk about
When discussing the use of media queries for Responsive Web Design, it is common to talk about devices. Devices are relevant in this context because we need to assess how content will be laid out and since a variety of devices come with a variety of screen sizes, determining the best layout for the content requires understanding of various screen sizes to determine how many unique or common layouts you will need.
The term used to determine this is breakpoint, which is the point at which your content no longer quite works in a given layout and you tell the browser to present a different/modified layout view (using those media queries mentioned).
Breakpoints are usually expressed by the viewport width in a unit like pixels, however, it is common (and unfortunate) to refer instead to a device (generically, like “smartphone”, or specifically like “iPad 4") as shorthand to the breakpoint/layout need instead of expressing the breakpoint value and unit like “480px”.
In contrast, when talking about adaptive content, you may refer to devices and the platforms/operating systems used to understand different constraints and interactions to determine your content model and need for versions of content in the course of authoring it (making it adaptive!).
So when you hear that the full-screen image carousel is not going to work well on smartphones, you can’t tell if people mean the images and text were not created with adaptability in mind and there is some platform or device-level constraint for the distribution of that content, or if they mean a full-width image carousel is not an optimal presentati0n for a narrow layout like a 320px breakpoint commonly seen on many types of smartphones.
By this point, who knows what conversation you are having.
3. Flexible media is a content AND a layout problem
Our lives would be much easier if textual content was all we had to deal with. Not because it’s easy, but because it’s a lot more stable than handling other kinds of content like images, video, audio and so on, which have less established or commonly standardized methods (of making responsive).
A primary concern in the course of the making a site responsive is content reflow. When we think about text, the complexity lies in preferences of presentation, for which there is a vast array of options in CSS to satisfy the most sophisticated and nuanced design, including the use of custom fonts, icon libraries and animation. And while different browsers still might be tricky about certain situations, all support every character found in human languages (and even some others).
When it comes to other content types however (namely images, audio and video), we are not yet offered a consistent reliable method to accomplish all we want to do in service of presenting it responsively everywhere we need. It is definitely possible, but far more laborious than textual content. And since flexible media is the 3rd leg of the RWD technique stool, it becomes a pretty large part of your effort.
Many responsive presentation techniques end up requiring transformation of the content itself — cropping, re-optimizing, converting codecs, etc, and here lies the conversation bottleneck when you intertwine Adaptive and Responsive issues.
Now when I hear “I need more than a Responsive site, I need it to be Adaptive” I try to put aside the responsive issue for a moment and start asking questions about the content type because in my experience to date, that’s the real decision point that is needed. It becomes a dependency for Responsive progress and if you are going to address the content lifecycle, might as well look at it holistically and properly. (Also, this is how you make content strategy happen when your place of work doesn’t understand content strategy).
The plainest way I can think of to put it is that the responsive needs become content requirements. This then feeds into the content model, authoring and editorial processes necessary to support your content lifecycle. RWD as an agent of change; you are basically forced to think about your content strategy when you need flexible media.
Now that’s messy. Let’s break it down further: We just want the content to display responsively, but we can’t because the content itself has an inherent limitation and needs to be modified (basically new content requirements). We are now talking about the content lifecycle itself if we are transforming it (whether that is done on the fly using a tool that manipulates images based on certain attributes, or manually by tireless photoshoppers off-shore, or something in between). You have a people, process and technology turducken, but you still don’t have Responsive in opposition to Adaptive.
Come to think of it, you have Adaptive in service of Responsive.
4. Conditional display, the final frontier of confusion
How could this get any more confusing? By creating conditions. This is the last category of problem I see that creates this faux-Responsive versus Adaptive situation.
You could say that if there is ever a condition that needs to be met for content to display that isn’t simply “content is X, show X here”, then this content is customized. All I mean by customized is there is some condition that needs to be met for the system to determine what content to display and sometimes how to display it.
We don’t really have a good term for this that I am aware of that is not customization (and sometimes personalization when the defining attribute is based on user values). I have heard plenty of smart people use the term Adaptive Content to mean customized content. And there’s another Inigo Moment™ for you. This is perhaps a simpler and more addressable issue: tell them what Adaptive Content means. This is a help-distribute-the-future opportunity. PS: Don’t be a jerk.
Maybe think of the hours of online and offline debate we’re saving ourselves in the long run if we stop messing this up.
Make a thing out of it
I hope this helps establish that this false dichotomy between Adaptive (Content) and Responsive (Web Design) is a non-starter. By understanding what’s broken about it we can hopefully help others understand both concepts better, diffuse contentious disagreements and perhaps prevent teams from going down ratholes of misinformed strategies as there is no there there.
Feel free to send this to a friend along with the 2 definitions above:
You can have adaptive content that is displayed on a website responsively (so it is more usable on any device with ease), and you can have adaptive content that is displayed non-responsively (in a fixed manner with a rigid layout, or even have different sites for different devices all using that same content).
You can also have a responsive site with content that was created exclusively for that site and no other uses (so, not adaptive), and a responsive site with content that was authored to be used on that site as well as on an mobile app, a kiosk UI, an email newsletter, another website and so on (adaptive).