On responsive web design03/19/2012
This morning I purchased this iBook called "Responsive Web Design" (brought to us by A Book Apart: Brief Books for People Who Make Websites), it was literally the ONLY book that came up when I searched for responsive web design, but fortunately, the exact one I was looking for anyway. So, reading it during my lunch break I came across this point which was a problem I did not even consider when thinking about having separate web and mobile sites for certain clients. Of course, Victoria (the Strategy and Media Veep here at Dirigo) and I had touched on it lightly in past discussions, for example when talking about including the "view full site" link at the bottom of a mobile page when one gets redirected to a mobile site when they are on a desktop or even when they are on a smart phone but still want to view the full site (I do this constantly). Sometimes, I get directed to an article within a content-rich site and I click "view desktop version" and then instead of loading the desktop version of the article, it loads the desktop version of the site (a surprisingly common problem, xkcd made a comic about it) and I lose my place and either need to go back and be okay with the mobile version, or search through the site again to find the real article. Ethan Marcotte, the author of Responsive Web Design reflects on his experience in this topic:
"Unfortunately, our early attempts at designing beyond the desktop have felt pretty similar to our old approaches, applying constraints in the face of uncertainty. A few months ago, a friend emailed me a link to an article she’d just read on her phone:
See the /mobile/ directory? The site’s owners had quarantined the “mobile experience” on a separate URL, assuming a page width of 320 pixels. But whenever that link is shared on Twitter, Facebook, or via email, visitors will be locked into that small-screen friendly view, regardless of the device they use to read it. And speaking for myself, the reading experiencewas, well, awful on a desktop browser."
I am going to call it the “separate but equal” way of design which I see being the conceptual opposite of Responsive Web Design (RWD). The separate but equal approach is simply not efficient, and more importantly, doesn’t follow the basic idea of what the Internet has brought us in the first place: connectedness and community. Creating separate arenas of the same content merely delegates some of us to one area of the Internet and others to the other side. We are not looking at the same content; we are looking at copies of the same content. The trick is to create a fluid design that looks beautiful on a wide spectrum of devices and browsers while at the same time, guide the user through an easy and intuitive experience thatfunctions based on the clients’ needs.
RWD has been a "thing" for a few years now, and had been written off initially as a trend by many thinkers and designers, like shiny buttons or apple-esque design, but even those thinkers and designers have come around to see RWD, rather than a trend, as a shift. It became tooimportant to just implement because it’s the thing to do, but to base their design on it because it is the way to efficiently marry desktop, tablet andmobile browsing.
One of those thinkers, Andy Hume writes: " Optimizing for One Web , instead of specific browsers/devices/individuals, is an ideal that is a profound part of being a web developer. It has to be at the heart of everything you design and build. If not, you’re doomed to write code and support an ever-increasing array of client platforms from whatever the browser landscape throws at you in the coming years. Good luck with that."
This is part of my ongoing personal project I am calling; "Learn New Things, Identify Their Importance, If It Is Important: Push The Programmers Into Learning the New Thing." I know that the programmers here are comfortable in their knowledge, which is mostly a goodthing, I just don't want them to get too comfortable. We can't innovate if we are not willing to learn more. HTML5 and CSS3 are the most important programming languages specifically for RWD. While our team is strong with these languages, we can always enhance our understanding especially on compatibility issues (with for example, the web developers nightmare: Internet Explorer *que evil music*). And while some programmers might push back, citing very relevant issues about compatibility, designers and programmers can and must meet in the middle, striking the balance of solid function and compatibility, and a beautiful user interface.
The thing to keep in mind—as time goes on, the compatibility issues of a specific application are less of an issue as more upgrade their browsers and systems and suddenly we are not just stagnant, but we are behind, having never ventured out of our cave of safety. These design concepts will not work for everyone, but I think going forward, we need to see these concepts as the default, then making the exceptions for the clients for which these concepts just don’t work, and those types of clients and projects will become fewer as time goes on and more adapt, but we will still be ahead and competitive (as well as more well-rounded). The idea that one-size-fits-all is exactly what RWD isn't and that's why it's a good base.
Here are some great examples of RWD done right. Resize your browser from wide to really narrow (like an iPhone) and notice how the elements shift.