White Paper: Responsive Layouts – The New Web Design Format

There is a lot of talk these days about responsive design, and for good reason.  Most large websites out there have seen huge upticks in their mobile traffic over the past year.  Not only that, but the trend seems to be increasing.  Some estimates claim that the majority of web traffic will be viewed on mobile devices by 2016.    We are seeing this growth here at Surge too.  In fact, just over the past six months, mobile visits to our company site are up over 25%.  This certainly appears to be a trend that will only continue, and it is simply a consideration no competitive company can afford to ignore. What this process reminds me of, in a lot of ways, is a media format change.  That is, fixed-pixel layouts (layouts that are the same size on any size screen) are the “Cassette Tapes” of the web world, while responsive layouts (layouts that adapt to varying screen sizes automatically) are the new and improved “CD Discs”.  And, as operators of any sort website or web app, it is our responsibility to stay current (or risk being left behind by our competition).  People are going to choose the provider whose service is the most tailored to them, and with more and more people doing more and more of their web browsing on mobile devices, these choices are being voiced and acted upon today. The thing about responsive design that is easy to forget, though, is that it is still in its infancy.  Although there are lots of loud voices out on the Internet proclaiming their way is THE way to do responsive design, the fact of the matter is that there are numerous ways to achieve a great experience on mobile devices. Just like any sort of tool, or design/development methodology, there is no “one right way” to do responsive designs.  There are a lot of things to consider, and usually the best choice will be contextual.  That is, a big part of choosing which way to achieve a great mobile experience is to take into account the needs of the client, and of their customers, and find the method that best matches that context.  That being said, here are the typical ways (great) mobile experiences are built: Native Application Put simply, this method involves building an “app” to serve the content of your website and/or web application.  This method has worked well over the past several years.  In fact, most users, if asked, would still prefer using a native application on their phone rather than using a web interface (through their phone’s web browser).   However, the tide is turning with this opinion (in our opinion, mostly due to the growing adoption of responsive design). Going the route of custom app creation has developed some problems recently, especially when it comes to Android.  One does not have to do many Google searches to hear endless stories about app developers developing for iOS first due to fragmentation of Android (and having to test and support their app on hundreds of different potential devices).  Once upon a time, going strictly iOS-first (and even iOS-only) was a sound approach.  However, with the gains in market share Android has been achieving over the past year (currently at 59%, worldwide), neglecting these customers can create quite an impact in your potential audience. Additionally, by going the app route, you have to keep your web offering and your app offering in sync (thus, creating two “products” to support).  For some projects, this additional overhead can make properly updating and supporting the product impractical. Separate Mobile Website One of the first methods for delivering a tailored mobile experience that became popular was creating two separate sites, a “desktop” version and a “mobile” version.  This method is still championed today, even by the likes of Usability Guru Jakob Nielsen. The potential problem with taking this approach, much like with a native app, is that you have two websites to support instead of just one.  Plus, both Google and Bing have come down on the side of doing responsive sites when possible.  Simply put, search engines take a user-centric approach in saying that content should not be duplicated across multiple sites, and users should not have to see a stripped-down version of a site (on mobile, content-wise) if they don’t want to. Responsive Layouts Using CSS There is a lot going on in this space, since it is so new, but the most common method for serving up different CSS files based on screen resolutions (smaller screens = smaller resolutions) is to use what are called media queries to get the screen resolution the user has, then serve up resolution-specific CSS elements (or even whole CSS files). In my personal experience, this method works great, most of the time.  However, it is not without its detractors.  Some even go so far as to call Media Queries “fool’s gold” because it does not take into account differing bandwidth concerns and lack of support for media queries on mobile browsers. Personally, I think this is a bit hyperbolic.  If your audience is primarily US-based (or in Western Europe), the media query support argument is moot (iOS Safari has supported them since v3.2 and Android has supported them since v.2.1, three versions back from current each).  Also, to me, the bandwidth issue is becoming more and more moot by the day, with carriers ushering people on to much faster 4G networks (which makes 3G networks even faster than they were, due to fewer people being on them). Still, these arguments do have a point in certain scenarios.  For example, if I was designing for parts of the world still using 2G technologies, I would take this advice to heart.  For most circumstances, especially for business applications, though, I just do not think this type of advice applies. Responsive Layouts Using Javascript Similar to using CSS, this method uses Javascript to serve different CSS files based on screen resolution.  Typically with this sort of approach, you will want to safeguard yourself by serving the mobile version by default (if Javascript is disabled), since that is a more likely scenario on mobile devices than in a desktop environment. This approach is probably the most fool-proof, but it does add added complexity.  To me, choosing between Javascript and CSS is usually choosing whichever method the implementation team has the most experience with.  Neither one, in my opinion, is terribly better than the other.  As such, personal technology preference (as well as what makes the most sense for the project) will weigh most heavily in my decision. So, Which Way is Best? So, you have decided you need your website/web-app to be responsive, which method should you choose?  Well, unfortunately, the answer is not very satisfying, because it is simply “it depends”.  These are complicated issues, and one-size-fits-all solutions tend to fall-down, sometimes hard, when the complexity gets high.  Plus, these issues are still evolving and maturing by the day it seems, and what works today may not work as well as what works tomorrow.  Just like any technology decision, the best choice will be made only after gaining clear understanding of the exact context you are applying a solution to. At Surge, we have helped a lot of clients walk through this process.  Typically, these sorts of decisions are not easy, but with important issues like this, they are simply too critical to avoid.  After all, if you knew, today, that between 10%-20% of your website/web-app visitors were not seeing a properly formatted version, wouldn’t you want to fix it?  I would assume the answer is “yes”, and if you are running a website with “normal” sorts of traffic, this IS already happening to you.

Leave a Reply

Your email address will not be published. Required fields are marked *

America's Best Software Engineers, On-Demand, at an Affordable Price
Surge Forward With Us