Luca Passani, CTO @ScientiaMobile, January 2017
I had not blogged for some time, but listening to a conversation that involved Ethan Marcotte and Karen McGrane the other day inspired me to hit the company web log with a new post. The reason for this is because I heard something that I consider big. Very big.
Ethan and Karen are two venerable authorities when it comes to the topic of Responsive Web Design (RWD). Plus, they have real experience with web projects, including mobile web, for large enterprises. This is why, when they speak, taking notice is often a good idea. The conversation on the status of RWD was no exception, because there was a point made by Karen, which Ethan subscribed to, that Adaptive Design is not really defined the way a lot of people say it is.
Before I get to the point, let me revisit what Adaptive Design means to many and how it relates to RWD.
For most authors who have embraced Responsive, Adaptive Design is the evolution of Progressive Enhancement and Mobile First. The adoption of those two philosophies, augmented with the ability to address a set of form factors through Media Queries and breakpoints, is the basis for what they call Adaptive Design. Media Queries are essentially conditional CSS rules that can be evaluated (client-side) based on media features, such as certain minimal screen-size intervals (the breakpoints) in order to tailor the UX for users of smartphones, tablets, and desktops.
The Crux of Adaptive vs. Responsive
This is all very good, but there is a problem. If you have a smattering of RWD experience, then you know that Media Queries and breakpoints are the foundation of Responsive Design as well. It can easily be argued that the definition of “Adaptive” provided above fails to offer a clear separation between the two.
For reasons that appear sort of religious to me, I have always perceived a dogma among some authors that Adaptive Design and Responsive Design are separate approaches to making the web mobile friendly. Where the actual differences lie, though, has never been clear. The first article on Adaptive Design that comes up in Google is a good example of this. According to the author, the difference between the two approaches boils down to whether those DIV containers snap to the breakpoints or simply flow when the user resizes the window….hmmmm. Perplexing, not a world of difference if you ask me. I have seen a lot of sites featured as prominent examples of RWD that have their grids snap into place as browser windows are resized. Would it make sense to say that Responsive and Adaptive are the same thing really, or is there more to it? Let’s go back to the conversation with Karen and Ethan now.
What is the Real Difference Between Adaptive and Responsive Then?
The first question was about the difference between Adaptive and Responsive Design. Karen responded first. I was amused, and very surprised, to hear her discard the traditional explanation of Adaptive and go straight to an alternative definition: “Adaptive is server-side,” “Adaptive is when you need to get the server involved,” “There are very solid cases when you want to serve different content,” and even “there are […] limited […] cases when you want to serve something device-specific,” “there are cases when you want to tailor the experience to the context that someone’s in, and that might involve what you think is mobile and what you think is a different context,” “we often represent Responsive and Adaptive as they are in competition when in fact it doesn’t work that way.” Ethan Marcotte basically subscribed to what Karen said.
Wow! Just Wow! Adaptive Has Been Redefined in Front of My Own Eyes
A taboo is broken. Several taboos in fact. The mobile context exists (a few happily argued that it didn’t in the past). There are valid reasons and use-cases to serve different content and different user-experience to users of different devices. For those cases you may want to leverage the server-side to understand which version of your content to provide. This is quite a change from a time when Karen used to write, “It’s time to stop imagining that smartphones, tablets, and desktops are containers that each hold their own content, optimized for a particular browsing or reading experience. Users don’t think of it that way. Instead, users imagine that each device is its own window onto the web.” This excerpt says that Karen McGrane 2013 did not believe that a mobile context existed, however the 2016 version obviously does.
I speculate that these years of experience working with large enterprises have revealed that the mobile context does exist, that there are cases where the context does call for different content, and that DIVs that may or may not snap (on devices for which resizing the browser window is not an option!) can hardly provide a very compelling story to enterprises who need to address different browsing experiences for legitimate business reasons.
Why the Server Matters in a Mobile First World
For those who tuned in to the world of mobile only recently, this shift in the definition of Adaptive Design may not appear as such a big deal. But to those who have been cold-shouldered for years for maintaining that the server plays a key role in providing great mobile web performance, this is a big one. At the end of the day, web professionals need to make pragmatic decisions about what is best for their customers and their users, as opposed to taking ideological approaches in the name of a presumed purity of the web that never really existed.
As Karen says, Responsive is great, but there is no reason why organizations should set artificial boundaries to what technology offers them to provide great mobile web performance.
The End User’s Experience and the Business Models of Organizations
Web and mobile users are simply consumers that need to complete tasks. What matters to them is whether the tasks can be completed quickly and easily. They don’t care if the mechanisms that brought them the service are built with Media Queries, or if a little magic was used by the server to tailor the experience to their specific device or class of devices.
By the same token, companies that create mobile services do so because they have business models. Advertising is the most obvious example here. Why should companies be forced to serve the same ads, or provide the same UX to users of different devices when this would not serve their business goals? They shouldn’t.
How Should We Define Adaptive Then?
Of course, here at ScientiaMobile, we have always known that involving the server is often a good idea. If I were challenged with the question, “What is Adaptive Design?” I would go for something close to Karen’s definition: Adaptive is using techniques that may involve the server to achieve the goals of the project stakeholders. This usually means striving for a great user-experience. I say “usually” because there are cases when the business model clashes with maximum friendliness, with ads and banners (loaded at a performance cost from third-party Ad-Networks) as the most obvious example.
Of course, the downside of such a definition is that it is very broad. It provides little indication on how things should be done in practice. JavaScript tweaks to the RWD UX on this or that class of devices would obviously fall under the umbrella of Adaptive, but so would the opposite extreme: providing multiple separated views for classes of devices, or even an old-style mDot site for mobile phones (i.e. blasphemy to the eyes of web purists).
Déjà Vu and the Future
For people like us who were building mobile websites as early as 1998, all of this is very Déjà vu. In those days, the Server was all one had to address the limitations of the mobile medium. While RWD is a great advancement to reduce the cost of mobile development, it’s obvious that adding the server will always yield RWD++. In this context, Adaptive doesn’t have a definition set in stone and, with a little push, the term can be made to include techniques that have been adopted along the way as technology has allowed.
This includes:
- Using MVC frameworks to dispatch requests to different views while preserving URL uniqueness (same URL for web and mobile content).
- Progressive Enhancement and Mobile First.
- RWD.
- RESS (Responsive Design + Server Side Components).
- Server-Side resampling of images (included when used in conjunction with responsive images).
At the cost of some controversy, I am tempted to throw in the following as well:
- Redirecting mobile phones to a mobile-only site with a separate URL (after all, the separate mobile site, RWD and MVC were grouped under the umbrella of what Google called Dynamic Serving at some point).
I argue that Adaptive Design today simply encompasses all of these techniques. A few years back, we started seeing people discounting the Server just because a lot could be done with the client. It did not make a whole lot of sense to us. After all, why limit oneself to the client when the server can so powerfully support us? And above all, why renounce the server when technology is bringing the web to wristwatches, smart TVs, glasses and a plethora of new form factors on which a pure RWD is almost guaranteed to fail?
I’m happy to see that some important experts have finally started to see it our way. Call it RESS, call it Mobile Context, call it Adaptive Design or call it whatever you wish. Server-side undeniably plays a key role and the pundits have come full circle about it!
