Responsive Design vs ‘m.’ Sites
The segregation of the mobile experience to a subdomain, the notorious ‘m’ domain, seems a little old school in 2014. It’s a legitimate question, in the fast-moving realm of mobile-web development, whether you should even consider having such a segregation.
In this article, I start from the premise that few entities use an ‘m’ domain any more, and present a few reasons why not. Then, playing devil’s advocate, I’ll offer a few reasons why you might want a separate subdomain to which to redirect your mobile user base.
Why nobody does it any more
RWD All The Things
The advent of responsive web design, mobile-first design, and progressive enhancement as design patterns have been enthusiastically embraced by many designers and developers. They have changed the way the business of design and development is done. Site designs, especially those built from scratch, are increasingly built from the ‘bottom up’ rather than the ‘top down’. Rather than creating a beautiful, feature-full site that will display well on large desktops and taking away or hiding functionality as the user’s screen shrinks to mobile, a mobile-first design would start with a design that is attractive and functional on the smallest screen. From there, the designer progressively enhances the interface towards the high-definition desktop experience.
Going further, Scott Jehl recently suggested not so much a “mobile-first” strategy but rather a “global-first” strategy. Design a set of styles that are must haves across all screens and then enhance depending on a browser’s capability, dependent on what Scott terms a “cut the mustard” set of tests.
One brand, one codebase, one domain
One of the reasons that the ‘m’ domain was adopted earlier included the need to maintain separate codebases. A mobile team might maintain one, a web team the other. There was the idea that the ‘m’ site had to perform differently from the ‘www’ site. But the maintenance issues inherent in this strategy are daunting.
Maintaining large staffs of developers and ensuring data coherence between two front-end codebases and, presumably, one backend system present maintenance nightmares. This schizophrenic web-to-mobile presence might be
damaging to your brand if a user becomes confused because the site on their iPhone looks completely different from the site on their desktop.
Rather than maintain two codebases and potentially confuse a customer, a small, agile team can use modern strategies to provide a clean, fast, responsive experience that
degrades well from desktop to mobile.
A functional site such as Ancestry.com has made the move to an acceptable web-to-mobile responsive site that works well.
Why it’s still done
Legacy code and the mirage of mobile
Some sites have embraced new technologies, either creating a new mobile- first web presence with a site redesign or converting their legacy codebases to support responsive design. Other sites have taken the alternate strategy of segregating their ‘www’ and ‘m’ domains and presenting different user experiences
A good example is the e-commerce site, Sephora.com. Visiting www.sephora.com takes you to a non-responsive, standard desktop site with a big slider and many (tempting) products ready for the shopper to add to a cart. Visit the same site on your phone (or go to http://m.sephora.com on your desktop), and you are directed to a very nice ‘m’ site that looks completely different from the ‘www’ site.
While the shopping experience is just as tempting, it did take me six taps to add an item to my cart versus three on the desktop site. Clearly the large product line has obliged the mobile team to triage inventory in a different way on the mobile sites, simply to be able to display the products.
While I do not know the makeup (no pun intended) of Sephora’s development team, I am guessing that the large inventory of the company made the managers choose to divide the codebase into the two different domains as they are displayed completely differently on the different devices.
I would bet that the legacy codebase presented large challenges for anyone advocating mobile-first, responsive design strategies. This codebase has been around a while. A quick peek at the source code reveals the use of jQuery 1.6.3, and rather than convert a large, mature e-commerce site, the decision was made to create a separate mobile site. For a large, mature company like Sephora, this strategy may make good sense. A look at the ‘m’ site’s source code reveals jQuery 1.8.3 correctly loaded in the footer in a freshly-compiled concatenated file, with modern touches like lazy loading libraries and browser detection.
As with every design decision, the pros and cons of a strategy must be weighed before starting out on what could turn into a redesign. If your company has the luxury of starting a new web presence with the latest technologies and/or is a small shop, it makes more sense to take advantage of the latest and greatest in responsive, mobile-first design patterns.
If, however, you are dealing with a large, mature, legacy codebase, management dictates certain designs, and/or your team is large, you may be called on to fork the codebase and create a new mobile presence. As long as two codebases can be maintained effectively by your company, it might be a potential strategy for you. You could look at it as a way to ‘reboot’ your web strategy, allowing you to create a new ‘m’ site that might evolve to be a truly mobile-first site that can meet your ‘www’ needs and enable unification of the sites in the future.
If you’re interesting in learning more about Responsive Web Design, check out our new book, Jump Start Responsive Web Design, written by Chris Ward.