In early 2010, when I started developing the framework for a mobile web experience for Discount Tire, there were two approaches to choose from. The traditional, typical route at the time was to build and maintain an independent mobile site. The emerging new hotness would very soon be coined 'responsive web design'. I struggled mightily with that choice. Here's what I was thinking.

Avoiding m.ediocri.ty

Mobile sites, typically using m. or mobile. as a subdomain, were generally pretty weak back then. Lots and lots of companies would redirect iPhone and Android visitors to their cool new mobile 'site', where we'd often find a handful of the full site's main features, maybe less, laid out so the links to call a store were nice, big, easy-to-tap buttons. Great. Unfortunately, just as often the real content of the site was grossly pruned leaving an unsatisfying shell. Developing all that content twice is a huge commitment, a huge pain, and many sites just didn't bother.

I wanted all the core functionality of the long established Discount Tire website to be available on the mobile site. But it also wasn't enough to simply not be mediocre. I wanted the mobile site to be delightful and awesome, not just passable.

So do we build another one? Recreate the functionality with a new application for the m. version of our domain? Duplicating it for the sake of mobile optimization seemed daunting and unrewarding. OK, so what's behind door number 2?

The Unnamed Future

A new approach had been simmering for a while, implemented here and there on a blog or personal site, and then slowly starting to take shape. The idea was that you could use new Media Queries in CSS3 to apply different layout rules based on the viewport's properties (usually specifically width). If your viewport was wider than a certain amount, say 1000 pixels, you could apply a set of rules appropriate for a desktop with lots of real estate. If the viewport were narrower, you'd apply a different set of rules, maybe rules optimized for a tablet. If it were narrower still, say below 500 pixels, then the phone-centric rules kick in. One HTML document delivered from the server, one version of the markup, but with multiple possible layouts depending on the organization of the stylesheet and the Media Queries. The concept wasn't brand new, but it had yet to get any real best practice endorsements, and still felt raw.

This media query usage would soon be bundled up with a couple other techniques and given a new moniker, 'Responsive Web Design'. The seminal article that combined those techniques and gave them the power of a name was published in late May 2010, a couple months after I started laying down the groundwork for our mobile experience.

Finding a Balance

Given a continuum of website experiences from crappy to awesome, I had to figure out how to get as many of our company's visitors toward the awesome side as possible. That meant covering a somewhat different looking user base than we see today. The lion's share of our usage was coming from IE7 and IE8 at the beginning of 2010. Firefox was still ahead of Chrome. Blackberries were still around. 3% or 4% of our visitors didn't have javascript enabled. This was the setting in which I had to figure out how to keep anyone from sliding towards the crappy side.

Setting up a stack of technologies to deliver this new-fangled responsiveness was difficult. The vast majority of our mobile usage was on iOS and Android. The browsers there were awesome, and could handle whatever we threw at them. The consideration there was for bandwidth, not capabilities. However the majority of our desktop usage was from browsers that couldn't handle the key component of this bold new direction, the CSS media queries. Those browsers could be wrangled with javascript, but we've always believed in progressive enhancement, and that the non-javascript experience should be 100% functional and usable, even if not as snazzy.

That meant that the site's full desktop experience, complete with marketing fluff scattered throughout, had to work as a minimum requirement. In order to assure that all the heavy graphics on the site would always show up on desktop browsers, we had to bake them into either the markup or a stylesheet. Doing that means that while we can visually hide them on a mobile device, we can't actually prevent them from being downloaded.

I was stuck between assuring that promotional banners would be guaranteed to show up all over the place for desktop browsers, and delivering a lean, efficient layout for mobile while not forcing the visitor to download graphics (or css or js files) that they wouldn't use.

A Compromise of Sorts

We ended up with a hybrid. We rewrote the markup for the entire site, freeing ourselves of the rigidity and insane verbosity of the tables we'd used in the past. But we only wrote it once, and can use it for both presentations. The m. subdomain resolves to the same document root as the www subdomain. The same java application compiles nearly the same HTML, regardless of the domain. There are a couple exceptions that make all this work. First, the calls for CSS and JS files are routed to different directories, based on the subdomain of the site. Second, some content is reworded or completely removed depending on domain context. There are pros and cons, of course.

Pros:

• One codebase. There are no mobile pages, or desktop pages. Every page is written with both contexts in mind.
• Easily understood separation of desktop and mobile layout and interaction by keeping each in its own file
• Better performance for mobile and desktop users, as only assets that are necessary for that context are placed in the markup
• Ability to conditionally modify actual content in any page (i.e. to remove promotional banner graphics in mobile context)

Cons:

• Visitor's are pushed to the mobile domain based on User Agent analysis. An unreliable, at best, mechanism that requires constant upkeep to be compatible with new devices and software.
• Having mobile experience on a different domain complicates some analytics efforts. It also makes marketing and advertising work harder to make sure ads are appropriately targeted.
• Search Rankings are adversely affected. The www. site's long standing search credibilitiy is not shared with or enjoyed by the m. site. Mobile has to start from scratch

In the end, we've been happy with the result. Our institutional unwillingness to forgo certain content on desktop mixed with our performance stubbornness made an Adaptive Design a bad fit. Having a mobile experience on a separate domain from the canonical site has its drawbacks to be sure, but we did it with out sacrificing any real content*. Our visitors benefit from a much smaller document since we went to standards and shed the tables, and they don't download styles, scripts, or images that won't be used in their context.

When the time comes to do a mobile implementation for Discount Tire Direct, hopefully we'll be less beholden to these old IE browsers, and can roll with a sweet new responsive or adaptive layout.