The following is cross-posted from the RP3 Magnetisms blog, and is presented here in its original form.
As you read this, I have no idea where you are.
You could be on the train, on your way home, reading this on your smartphone. You could be sitting on your couch, reading this on a tablet like the iPad or Kindle Fire. Or you could be sitting at your desk at work, reading this on your computer, but the numbers show that this is becoming a less likely scenario every day.
And in the end, it shouldn’t matter. People today are confronted with a staggering amount of Internet-based media, from online news sources to blogs to streaming video and audio, and increasingly they’re ditching the traditional computer to consume it.
The Hard Numbers
Here are some stunning facts on mobile adoption compiled by Luke Wroblewski, author of Mobile First (A Book Apart, 2011):
- Smartphones were predicted out-ship laptop, desktop and notebook computers by 2012. They did so in 2010.
- Traffic to mobile websites tripled between 2009 and 2010. In 2010, traffic to mobile sites grew by 600%.
- By 2015, more than 50% of Americans who access the Internet will do so on mobile devices only. This is already true in Asia and Africa.
Every Website Needs a Mobile Strategy
This infographic demonstrates nicely the uncertainty of how your visitors will access your website.
It doesn’t matter who you think your customers are, or what platforms you think they might be using to visit your website, in the end you need to realize that you have no control over the means by which visitors come to your site. If they have a lousy mobile experience when they click through a Twitter link on their iPhone, they’re not likely to come back when they sit down at their computer later.
So what strategies are out there, and which makes sense for your site? Here are a few of the options:
A Separate Mobile vs. Desktop Site
Since the days of WAP-enabled Palm Pilots, this has been the default option for crafting a mobile experience. A separately-coded site, living at a different URL (often something like m.website.com), which may or may not be drawing on the same content as the more traditional “desktop” site.
An advantage to this approach is that mobile users get an experience specifically crafted for them. These sites are lower “weight” (that is, smaller photos and other files that transferred more quickly on slow mobile networks) than their desktop counterparts. Also, the experience is often tailored to the tasks mobile users were more likely to be interested in, such as finding the closest location of a retail store, or performing some other quick task that could be accomplished in just a few taps.
The downside is that mobile websites are often stripped down versions of their larger, desktop selves, and a mobile user searching for something in particular might not always be able to find the information he was looking for, even if he knew it exsited on the desktop site. Sometimes mobile sites look so different from their desktop counterparts in terms of design and branding, that the connection between the two would be completely lost to the user. Also, there were more problems with implementation, including such problems as “server attention span,” wonderfully displayed in this XKCD comic. Have you ever clicked on a link you saw in your mobile phone’s Twitter app, just to end up at a mobile site home page with no way of retrieving the actual content you were looking for? I have, and it stank. Another disadvantage is that poor implementation can sometimes mean a mobile experience gets pushed onto someone not using a smartphone, such as when sites detect Mobile Safari on a user’s iPad, and serve their iPhone site onto a 1024 x 768 iPad display.
Responsive Web Design
If you’ve been atuned to the world of website development in any way over the past year and a half, you likely have come across the term “responsive web design.” This is the methodology, popularized by Ethan Marcotte in his book Responsive Web Design that allows one website to be coded in such a way as to immediately conform to any screen size, from the smallest phone to the largest high-definition display, instantly and automatically. The term “responsive” is an indication that such accommodations are made on the fly, so that if you took your browser window and made it narrower and wider, the design of the page would change while you watched. It’s a terrific concept, and one that I’ve adopted as a technique for building websites, but as with anything else, it has its notable pros and cons.
Responsive design’s chief attraction is having only one website to maintain. Perhaps in this day of content management systems and data stored in databases this isn’t the biggest issue in the world, but when working in large teams having multiple front end code bases can cause major maintenance headaches. Keeping a consistent brand is also easier when you’re only dealing with one website. Another pro is you’re not limiting yourself to just “mobile” vs. “desktop,” but rather preparing your site for all the 7 inch tablets, 10 inch tablets, 5 inch smartphones, etc. that are on the market today, as well as those that have yet to come.
Unfortunately, responsive web design isn’t the panacea to all your mobile ills. Responsive websites are much more complex than their fixed-width counterparts, which increases development costs (although these costs are still lower than having to build out separate “desktop” and “mobile” sites). In addition to whatever your “default” view is (and whether that should be the mobile-first approach or desktop-down is a question best left for another post), you need to code in all the variations of the design based on different “break points.” Another problem, one which the web development community has been grappling with, is what to do with images and other media items. If you have a large, full-bleed slideshow on your home page, you could simply use stylesheets to scale down your photographs, but in the process you are pushing a much larger file to mobile uses than they can actually use, chewing up their bandwidth caps in the process. It’s a problem with many possible solutions, but none that will work all the time and in all the cases.
The third major option in the world of mobile web is to build an OS-native version of your web application. This is an especially attractive option when you have an application that involves a lot of interaction on the user’s part. However, it is somewhat daunting in its scope because you now have to code your application in a completely new language and deal with the quirks of multiple platforms and vendors. Facebook’s failed experiment with HTML5 in its iOS native app points to the pitfalls in trying to tie together a cross-platform mobile strategy and the continuing need, at least at this point in time, for a native-code approach when building mobile apps.
The “Mobile Web” is no longer a novelty, nor some ideal on a distant horizon. It’s here, now, and website owners need to have a strategy for it. It’s no longer enough to say “my visitors don’t come to my site on their phones” because increasingly that is no longer true. Provide your visitors with a great mobile web experience, and they’ll become loyal customers wherever they go.