In the old days (just 5 to 7 short years ago), the big problem in Web Design was browsers (well…Internet Explorer to be fair to other browsers). Really, the only major decisions were (1) What browsers to support, and (2) Whether the layout was going to be fixed or fluid. The sizes of display monitors to consider weren’t much more than 3 (SVGA, XGA, etc.), and it was all landscape orientation for the most part. Those were some good times, eh?!
World War D
Welcome to the New Normal. Devices have taken over the Web access space, almost completely wresting power from the mighty Personal Computer. These Web-enabled Devices come in so many different shapes and screen sizes. Their screens do funny things like rotate when you turn them sideways. They all have Internet browsers, and all of them seem to behave differently from each other just like their ancestors did. Some of them have “sharper vision” than others [Retina]. If these Devices were a living being, I believe Prof. Charles Xavier would have a much stronger interest in him/her/it than the rest of us probably would.
These Devices make the Web seriously unpredictable. We have had this uncertainty in the past, but never on this scale. The number of Web-enabled Devices currently in use today means that it is no longer realistic to design Web sites manually considering every screen size. This new Web is – for want of a better word – Restive, and it is this “Restiveness” that makes Web Design today so annoyingly painful and tedious. It really doesn’t matter if one is designing a new Web site, or tweaking an existing Web site, it hurts either way. And we are still just dealing with Tablets and Smartphones, even as new classes of Web-enabled Devices like Wearables and Autobles [automobile-based Web-enabled Devices] are coming to the fore.
Unfortunately, we can’t put them [the Devices] all back in their boxes and send them back from whence they came, so we’re all just going to have to embrace this “Restive” nature and adapt to it. In truth “The wind is restive to him who has no understanding of that which determines the way in which it blows”. Our deficiency, no doubt, is in our understanding.
A Tale of Two Grandmasters
So imagine it’s 1932 and you own a Kung-fu Dojo in Foshan. You are the head of this very popular Dojo and also a Grandmaster. Well, one day, a quirky, overweight, Panda-esque stranger from another province walks in to challenge you. You accept the challenge [as indeed you must to protect your honor] and a duel ensues. A matchup that you expected to quickly end in your favor [remember you are a Grandmaster and your opponent is seemingly unwieldy], results in your defeat [with hopefully none of your students watching]. So what’s the problem?! You’re awesome at Kung-Fu, but you were caught unawares by an unfamiliar [and seemingly superior] set of techniques used by an unfamiliar challenger. Further review of what happened will enable you craft a counter-measure and perhaps redeem your reputation in a later bout.
This scenario is analogous to the multiple-device-laden Web of Today. Putting all these Web-enabled Devices [mobile and non-mobile] in the role of our “Stranger in the Dojo”, our Web Site [“You…the Dojo Owner”] was beaten up quickly and decisively [i.e. the web site could not adjust its look-and-feel in response to the numerous and different Web-enabled Devices in active use]. As time progressed and our understanding deepened [and as our wounds healed of course], we became better in successive bouts. It’s not that we had any chance of winning, but we were taking longer to get knocked out of a bout by this mysterious challenger, let’s call him “Restive”.
Were we going to keep challenging “Restive” to endless bouts after we learned one of his numerous techniques?! Clearly, he had a retinue of ‘moves’ that were prodigious and unpredictable. Clearly, confrontational adaptation was not our best strategy because although we were getting better and countering him on the techniques he had exposed, we were still getting beaten up whenever “Restive” changed strategy and introduced a new technique. Clearly, we have to change the game. We clearly need more ‘understanding’. Our honor and reputation [not to mention future revenue opportunities from our Dojo] were at stake.
So the goal is clear: become as good as “Restive”. Coming back to the world of the Web this basically means that our Web site is capable of dealing with any device that wants to access it. And just like there are different kung-fu styles like ‘Bak Mei’ and ‘Wing Chun’, the two predominant approaches right now for dealing with this challenge are ‘Responsive Web Design’ and ‘Adaptive Web Design’. We can either build on these two concepts, or develop another foundational approach that will enable us keep up with “Restive”. So let’s consider our existing options first.
Responsive Web Design
It is said that CSS Media Queries is the cornerstone of Responsive Web Design. However, looking at it critically, CSS Media Queries will never enable us become good enough to decisively deal with our Challenge. The reasons are numerous, but I’ll mention just 4:
- It [CSS Media Queries] cannot distinguish between a mobile device and a non-mobile one;
- It cannot definitively deal with form-factors e.g. tablet, phone, etc. and platforms like iOS, Android, etc;
- It is not modular-friendly;
- It is not elegant enough [too much markup required] especially on large and elaborate Web sites.
So in a nutshell, we can’t ‘train’ with this because we can’t ‘win’ with this. CSS Media Queries is based on CSS, which happens to be a stylesheet language. As a result, it is not best-suited for a lot of tasks [just like the 4 items previously listed]. So forcing ourselves to build on this approach would be considered pure folly.
Adaptive Web Design
Adaptive Web Design as our second approach holds much promise, once we can get our head around what it actually is. For some, the difference between “Responsive” and “Adaptive” approaches is that the latter is server-side. And yet for others, Adaptive Web Design focuses on more than just screen size, delving deeper into actual device features and capabilities.
Clearly, Adaptive Web Design is quite mystic and vast. Its origins stem from the concept of “Progressive Enhancement”. As much as I appreciate the need for this high-level thinking, how exactly am I going to whittle all this down into a core set of tactics that will help me build Web sites that adapt to all those pesky Web-enabled devices?! Because lest we forget our Challenge so soon, the ‘fists’ of “Restive” [our ‘Challenger’] are made of mobile Web browsers that come at you with blinding and unpredictable speed, and when they ‘connect’ with the <body> [Sorry! I couldn’t resist!], they do some serious damage.
So is Adaptive Web Design the way to go?! I’m afraid not, and here’s why:
- Heavy on concept, very light on strategy and practical tactics
- “Confusion of Chronology” of its underlying concepts [i.e. 3 layers of “Progressive Enhancement”] in practice. For example, does it make sense spending time on rich semantic markup when I haven’t exactly figured out how I’m going to implement device adaptation (screen size, capabilities, etc.)?! And is the term “rich” subjective?!
- Searching for information on Adaptive Web Design seems to lead to more questions instead of more answers [try Googling ‘Adaptive Web Design Tutorial’ and you’ll understand what I mean]
As a Web Designer looking at all of this from a ‘Building or Tweaking a Web Site for Multiple Web-enabled Devices’ standpoint, it seems that employing Adaptive Web Design would take more time than is reasonable to understand and to implement in a definitive way.
So let’s try a new, different, and more-focused approach, shall we!?!
The Restive Way
We don’t have all the answers yet, but just as the “Devil” is in the “Details”, I’m pretty sure that “Ip Man” is in our “Method”.
So our ‘Challenger’ is wily and unpredictable as has been already established. To ensure we maintain equilibrium, we have to become an equal and opposing force, a ‘yang’ to his ‘yin’. This foundational approach is referred to as “Incremental Zen”. In other words, to be a worthy adversary to “Restive” we need to be his mirror image.
Incremental Zen is all about “Eventual Togetherness”. In an operational sense, it is the Chief ‘Kumbaya’ Coordinator, and it is focused squarely on enabling the “function” that will give our Web site the ability to become and remain “in-sync” with all Web-enabled devices. In other words, does the web site look and feel “ok” in the device’s browser [or viewing interface], and if not what is the mechanism for harmonization. This is the foundation of Restive Web Design.
Being that the nature of the new Web is “Restive”, it’s extremely difficult to know how every new Web-enabled device is going to behave. However, in the context of Web browsing, we are sure that all of these devices will have a browser [or some similar viewing interface that adheres to certain laid-down standards] and that browser will have a viewable area [of specific width and height].
So now that Incremental Zen as our foundational approach [towards dealing with our ‘Challenger’] is now clear, what is our overall campaign plan?! There are two aspects to our overall strategy: The first is to understand what the likely capabilities of “Restive” are; and the second is to quickly adapt whenever a new capability of his is discovered.
In the context of Web Design, we need to:
- Build (or Tweak) our Web Site in anticipation of the Web-enabled devices we know to be in active usage. As regards tweaking, a lot of Web sites in existence today are designed for a “Personal Computer Experience”, so it’s essential that we can fix them to become “viewable and usable” with the different Web-enabled devices in active use by the target audience;
- Constantly evolve our Web Site until it is ultimately adaptable to every Web-enabled device in existence. This will happen on an ongoing basis as we discover new Web-enabled devices [especially their characteristics], and as those devices rise in popularity.
So understanding the “browsing” characteristics of all the devices we currently know about is critical, even as we learn about new ones just coming into existence. Also, it’s very important that we can update the adaptability of our web sites in an intuitive manner.
So now that the Strategy is clear, what are the conceptual actions we are going to have to execute?! It’s possible to come up with a laundry list of means to our end. However, being that we are more concerned with ‘look-and-feel’, we can define these three major sequential tactics:
- Surveilling: Getting some basic initial information about the device that is visiting our Web site, and also ongoing information on its behavior while on the Web site;
- Marshalling: Using all this information gathered from “Surveilling” to determine the action [or the set of actions] to take, and when to take them;
- Triggering: Using instructions from the Marshall to execute actions in response to specific triggers
The First Tactic in our troika is “Surveilling”. We have to know certain things about the device as soon as it requests content from our web site, the most important item of which would be its viewport width. We also need to know its pixel density, and a few other things. In addition, how this device behaves while on our Web site is also important. It is also worthy to note that the Intelligence gathered is persisted and available for use later. This intelligence gives us a better way of understanding just what is going on at every notable moment. In other words, we need to keep close watch on our ‘Challenger’ [“Restive”] and his every move.
The Third Tactic is “Triggering”. Since we now know what style rule to apply [and when], we can simply use the ‘addClass’ method of JQuery to apply whichever CSS class is selected [by our “Marshall”] to the pre-defined DOM [Document Object Model] element. So, if we have a style rule for “devices that are between 480 and 640 pixels wide”, identified by the “640-c” class, we can add that class to the <body> tag via the class attribute. By doing so, all the style definitions we have defined for this kind of device-class will be in effect. If it happens to be another device-class, we can remove the “640-c” class, and replace it with another. In other words, when we see the technique in play by our ‘Challenger’, we know how to defend against it, and we do just that.
So we now have a conceptual basis, a clear strategy, and itemized and discernible tactics for our new branch of ‘Martial Arts’. So what do we call it?! Well, I can’t think of any cool sounding names right now, so let’s just call it “Restive Plugin” [It turns out that the “Shameless Plug” is not entirely forbidden in Martial Arts].
The Final Showdown
The Stage is Set. The combatants are ready. It’s time for battle. Who will be victorious and who will be banished from Foshan forever!!! Ok, maybe I’m being a little bit too dramatic, but you understand that the stakes are high. “Restive” is here and he doesn’t seem like he’s going anywhere. We’ve spent a long time developing our method and it’s now time to put it into practice. So, without any further ado…”ROUND ONE…FIGGGHHHTTT!!!”
“Restive” unleashes his opening gambit with the “Sideways iPhone 4” [iPhone 4 in Landscape] technique. We know that the iPhone 4 viewport is 960 pixels wide in Landscape. We can then define a breakpoint from 640 to 960 pixels accordingly to catch this scenario, trigger a class addition to the DOM, and successfully defend against this approach. But what happens when he [Restive] follows up with the “Upright iPad 2” [iPad 2 in Portrait] attack?! With a viewport width of 768 pixels in portrait orientation, it matches our previous viewport, and is obviously meant to confuse us into using the same defense mechanism, but we can’t fall for that trickery, can we?!
I believe it’s safe to say that our “Surveilling” and “Marshalling” capabilities must be further honed to ensure that they are robust and also work well together in defending this cheeky fellow. “Orientation Awareness” techniques must be strong to ensure that we know when something is truly “Sideways” and when it is “Upright”. Simply changing our breakpoints from what it is now [640 to 960] to “640 to 768 and 769 to 960” might work for “Upright iPad 2”, but it will be totally useless in fending off the “Upright iPad 2-Nexus 4 Combo” flurry attack.
Oh my goodness! This guy’s good! The dreaded “Upright iPad 2-Nexus 4 Combo”?! For the uninitiated, the iPad 2 and the Nexus 4 devices have the exact same viewport width [768 pixels] in portrait orientation, so he expects that we will be totally confused, and trigger the same class addition, even though one device is a tablet and the other is a phone. We have to employ the art of “Form-Factor Detection” so we can distinguish between “Phone” and “Tablet”. By further enhancing our breakpoints using form-factor detection, our freedom and flexibility has received a boost.
The Battle rages on. We are still in it. Previously, we would probably have been knocked out by now, but our new “way” of combat has enabled us become supremely flexible and adaptable in the face of uncertainty and unpredictability. And even if “Restive” sneaks in a punch here and there, we’ll learn from our mistakes. It will get to a point when we will become ‘One’ with “Restive”. Maybe not today, but eventually we will.
The Saga Continues
So I apologize for going all “Wu Shu” on you in this post, but basically what I’m saying is that any effective approach employed in Web Design today that aims to solve the ‘Mobile Adaptability’ problem must strive for “oneness” with all devices. The Web today is “Restive” [as a direct result of all the devices that access it] and as such is quite unpredictable. We have to design our Web sites with full awareness and acceptance of this, and strive for “eventual togetherness”.
Restive Web Design provides an approach for dealing with this new ‘Restive’ reality. The technologies available to us in HTML5 are quite capable of solving the problem. We just need to bring them all together to develop user-friendly tools that get the job done in the way we have just described. And the Restive Plugin, is one of those tools that you can use today. There's way too much time spent on building mobile-optimized Web sites, and I think it's time we start taking some of it back.