Responsive Web Design or a Separate Mobile Website

The once popular argument about Mobile Apps vs. Mobile Web has given way to new arguments around Responsive vs. Separate and Mobile-Specific. I noticed a nice little thread of blog entries, starting with Jacob Nielson’s Mobile vs. Full Sites and carrying through Jeff Eaton’s Analogies are Like Dinners…, and on to a few others. I like the topic of building a single responsive website or a mobile-specific, separate version of your desktop site. It’s an important decision. It seems, though, that we’re all starting to blur the lines between the coding techniques and the content itself. Whether you can be seen everywhere with a single build, or whether you have a few device-specific versions of your website, the question of what content to promote and what content to limit for each device is still the same.

When it comes to content, I’d agree with Josh Clark when he says that it all depends on the audience and their goals. That goes for both mobile and desktop. When it comes to site-building, I’d advocate responsive web design 98% of the time. Furthermore, I might add that whatever a business’s goals are, the more content that you can have available, the better. The catch is that with the small screen real estate on mobile devices, all that content needs to be well designed and usable. This might be the single greatest challenge when it comes to mobile design.

Content is Not Code-Specific
As I just mentioned, the most important thing to remember when planning out and deploying a website build and mobile strategy is that no matter how device-specific your content is, that does not mean you need to build it one way or another. Responsive websites can easily hide or show content based on the same media queries that rearrange the menu or change font size. Just because your website is responsive does not mean it will look/be the same on smaller screens (you could argue quite the opposite, actually… if you look at our website, brolik.com on a desktop and on a phone, they’re very different, even though our site is responsive).

Since planning your content is required either way, I’d advocate a responsive approach to save time and money building and updating, and I’d throw out the idea of two or more separate versions of the same site.

More Reasons to Love Responsive
Beyond the “save time/money” argument, there are more mobile-related reasons to choose responsive web design. A big one is url structure. Have you ever been emailed a link to an article that sends you to a truncated, mobile version of that article even though you’re on your desktop? Or have you ever clicked on a link in Google from your phone, only to get redirected to the generic mobile homepage? These aren’t minor annoyances, they are relatively serious issues that can lead to frustrated users and bounces.

Another negative of separate site versions stems from the widespread recommendation that additional “non-mobile” content should be accessible through a link to the “full desktop version” of a website. This means that while users get the benefit of a streamlined, fast-loading mobile site, they get “after-thoughted” into a cumbersome and slow full site on their small device if they want some specific piece of content. The full site may even have a look and feel that’s different enough to be confusing, and users will need to “re-learn” the navigation. Plus, getting back to the mobile version of the page they linked from is likely a confusing task.

More Than Mobile
If you look a little beyond mobile, the same mobile vs. full site argument applies to tablets and any other “future devices” that we’ll inevitably see over time. Adding a third (or more) version of your site requires the same content planning as it would otherwise, but now the issues involving url structure and additional desktop content are multiplied. Then there’s the maintenance and content management of a site, which also get tripled (or more). Not with responsive, however.

Even though we don’t see as many articles written about tablet-specific content, we surely will. (And it’s not like they don’t exist). With responsive design, we can actually focus on the task of planning content, instead of the task of recoding.

So Please…
It’s important to keep reading and writing about the best ways to structure content for different devices and locations. This topic is incredibly pertinent to businesses and is often overlooked, even in 2012. But don’t confuse the content with the code. Build responsively for the plethora of reasons to, but don’t do it because you think your users deserve to see all of your content no matter where they browse from (although they do deserve that). Give your users all of your content, but give them what they want, when they want it. And please, make it easy for them. In the end, after everything is planned and executed, all the user cares about is that they can quickly and easily find the content they’re looking for, where and when they’re looking for it.