In the old old days mobile was never really a concern for most developers. All you really had to worry about cross anything were browser issues. Desktop screen sizes were debated back then, but they could be overlooked; the differences were not so great or prevalent, and the "fix" came relatively quickly as the industry settled on standard design widths and/or employed liquid layouts.
Around 2006 mobile begin to become a concern. The obstacles we faced developing for mobile were:
- Bandwidth, latency, and CPU issues were significantly worse than what we experience today.
- Screen sizes were much more varied, and smaller than today.
- Proxy servers might strip your site of images, flash (hugely popular back then), multimedia, or enforce throughput limitations.
- Only a basic set of media types were available and they were implemented inconsistently across browsers.
- Compatibility testing was extremely difficult due to the highly fragmented device market.
- The browser market was also highly fragmented.
- Browsers were relatively unsophisticated and OS or device bound
- Browsers rendered and/or supported languages inconsistently.
- There were competing protocols (WAP vs. HTTP) and markup languages (Wireless Markup Language - WML, XHTML Mobile Profile / XHTML Basic, HTML) which meant parsing issues and greater complexity.
To overcome these obstacles the general strategy to address mobile was "user agent sniffing", but still for the most part, for the vast majority of the Web, mobile was largely ignored.
Fast-forward to today and you would be ill-advised to overlook mobile:
Mobile browsing is rapidly consuming the Internet. The smartphone and tablet lifestyle is replacing laptops and desktop computers as the primary way we go online.
- Mobile Browsing: It Will Get Better and Worse by Chris Kelly of New Relic
The fact is, users consume your website on smartphones or some kind of tablet. I think this is pretty much common knowledge now.
When I asked LaunchWare founder Dan Pickett what he thought was the best approach for developing for mobile his answer was so succinct (and backed with experience) that it deserves quoting in its entirety:
We've generally found, UI/UX wise, though that the paradigm is so different that it generally requires a different set of controllers and views.
So I see three or four different levels:
- A responsive design for content oriented / non-workflow based sites (pure HTML/CSS/JS solution)
- A set of different mobile vs. traditional web views sharing the same controllers (use only when the workflow experience is the same on both paradigms, but still have request specs exercising both mediums)
- A set of different controllers and views optimized for each experience, with appropriate request specs for each paradigm. (we've suggested this approach in most apps - shared business logic, different views and controllers)
- A separate, mobile web application that talks to the main application client side via a service oriented architecture (this is usually the last progression before going native, and we only go this route if the mobile app is vastly different from the web application)
The later three allow for a phonegap or a similar solution so that the app can be listed in the app stores and can take advantage of some of the native functions of the device.
A Basic Plan of Attack
I find that for most development situations I encounter one of the following three plans of attack will work more than adequately:
Detect screen size via media queries to serve up responsive web design
Detect user agents to serve mobile versions of the website
A hybrid of 1 and 2.
Personally I tend to use option three. I like to separate concerns, and include responsive design within this separation since there is no one size fits all in mobile:
Now, oftentimes, people think about device detection as a "one or the other" sort of thing. Either you’re doing responsive design or you’re using device detection to route people to separate templates, and that you would choose one of those two options; you wouldn’t build something that uses both. But we’ve actually combined responsive design with server-side detection quite a bit.
- Jason Grigsby – Mobile-First Responsive Design Podcast by Sean Carmichael
An all or nothing approach really does not make sense as a rule of thumb. Let the situation dictate the solution.
Whatever approach you decide to take, keep in mind that there are a spectrum of user and business needs. Responsive may be the silver bullet for some sites on that spectrum, and for others not. For example my personal website is pretty simple so maybe detecting user agents to serve a mobile version of the site is not the best use of my time. In this case why not use Responsive Web Design and keep things together? More complex applications, however, may need to serve up specific markup and styles, take for example Basecamp mobile:
Only using responsive design for Basecamp mobile would have been like fitting a Prius body to a Hummer... under-the-hood it would have been all wrong.
- Behind the speed: Basecamp mobile
A final quote:
Create a product, don’t re-imagine one for small screens. Great mobile products are created, never ported.
- Mobile Design and Development by Brian Fling
Want to know when the next article is published? Subscribe here. Thanks for reading!