In my last post, I discussed some basic ideologies of framework for mobile web.  Some apply similarly to the “desktop web,” but in this post, I want to present a case for separating mobile and desktop web development, even while still maintaining the principles of Mobile First Responsive Web Design.

While it might sound nice to manage a single code base for all interfaces, it does not necessarily make sense to do so simply because it is possible with a big bag of coding tricks.  There are many reasons why an organization may wish to maintain separate projects for desktop web, mobile web, and even tablet or set-top web.  I often see the efficiency discussion overshadow the practicality discussion, so here is a list of practical reasons for maintaining separate (but logically connected) sites.

The list that follows is largely inspired by Why Separate Mobile & Desktop Web Pages?, Responsive Web Design Business Challenges, in addition to my own experiences building for the mobile web.

• Load Order:  The order in which to load page elements and execute scripts for a mobile site often have a different priority than the same page built for desktop viewing.  Since mobile data and processor speeds vary by device, by network, by location, and a number of other factors, source code should be ordered to generate the most important items first.  In mobile, that means content (including mobile advertisements) before navigation.  Resources load top-down based on the source order, so put content hooks high on the page and most scripts or navigation down lower.  Even a couple seconds delay with each page click in mobile makes for a more negative user experience.  Traditionally, desktop sites will conversely load navigation elements and many scripts near the beginning of the code, to be followed by page content.
• AJAX Interfaces:  AJAX interfaces provide a fantastic experience for desktop web browsing.  They primarily do two things for desktop browsing:  1) enable pre-fetching of hidden content to make page interactions very fast, and 2) enable slick UI interactions for users that do not require the loading of a new page with each click.  In mobile, both of these can be negatives.  Pre-fetching of content that may never even be used is a waste of bandwidth, memory, and processing power on a mobile, and quite often those fancy AJAX UI interactions would be more clearly served with separate full screen pages on the smalls screen.  After all, a mobile full screen is often the size of a desktop AJAX pop-up.  Separating mobile and desktop code bases allows developers to create the optimal hierarchy and interface design for each class of device independent of one another.
• Search Engine Optimization: It is not fully clear the impact of responsive web design on crawlers from Google and other search engines.  These bots do not represent themselves clearly as one specific device, and given the same exact URLs for both mobile and desktop versions of a site, there is some mystery in what this would do for search indexing.  For example, if your core site is a bare-bones Mobile First design that utilizes a number of scripts to dynamically add content for higher-level devices, then it is conceivable that a search engine bot that never triggers Javascript actions would never even see much of a site’s content.  Separate sites allows site owners to maximize SEO strategies for each without risking additional crawler confusion.
• Different Applications for Different Use Cases:   There is a different context to surfing the web by mobile, by tablet, by set-top, or by laptop, where each may be inspired by a different intention or purpose.  This means that it is not simply about adapting to screen sizes and input methods, but designing for multiple devices can mean designing different applications for distinct use cases.   Managing each variation within a single HTML file does one of two things.   Either it restricts design flexibility to the least common factors across all platforms, or it creates unnecessary code overhead and complexity in order to handle each case.  If the site is actually serving distinct use cases or applications, it is cleaner to maintain separate sites.
• Analytics:  Javascript traffic tools like Google Analytics can provide a ton of information about site visitors with a little snippet of script.  Many mobile browsers do not support Javascript, and for those that do, this script may often get left “un-triggered” because of slower speeds on mobile (or low placement on a page).  This is a classic case of something that works very well on desktop, but does not yet work as well on mobile.  Mobile analytics are best handled by server-side reporting tools.  It is important, however, to make sure that whatever combination of tools is implemented, that multiple tools are not overlapping in recording some individual visits in multiple places.  This is where maintaining separate mobile and desktop sites can really help delineate one set of traffic from the other.
• Images:  For responsive design, a developer would typically load a reasonably high-resolution image (larger file) that can be scaled down to fit smaller viewports.  You cannot do the opposite and host a low-resolution image and then scale up for larger viewports while maintaining image clarity.  Mobile bandwidth is at a premium compared to desktop bandwidth, both in terms of load time and actual cost too given tiered data pricing from most carriers.  By maintaining different sites, a developer can still build a responsive design, but serve images that are high resolution relative maximum size of the class of device rather than relative to all classes.  This results in smaller average image files, which means faster load times and less bandwidth consumption.  Depending on implementation, a CDN caching assets built for a wide range of desktop and mobile browsers can cause more difficulties when aggregated all together under one site as well.
• Videos: In desktop or even tablet design, the practice of embedding a video in a web page is fairly normal.  In some implementations, embedded videos even pre-fetch their content, so that it can be played automatically or without buffering delay.  However, in mobile design, this can cause a tax on both bandwidth and load times.  A better mobile experience for videos would be to add a snapshot image of the video (with a “play” button overlayed perhaps), which launches the full screen player when clicked rather than containing it to a smaller embedded box on a page.
• Code Overhead:  Nearly all of the challenges in this list can be overcome with some clever coding, but all of that code adds to the load put on the data channel, the processor and memory available to the browser, and are not “costless” to the user experience.  Every second counts, especially in mobile load time.  The goal should be to send the device the smallest amount of code possible, in priority order, to generate the desired experience.  All that extra code may create the desired effect, but in order to do so, it all needs to be sent to the device and processed.  Hiding elements with CSS, for example, may create just the right visual effect, but it does not stop the browser from loading all of it in the background anyway.  Every clever script for handling quirky IE desktop versions is magic on a desktop, but is completely wasted on mobile browsers.  Optimize.  Developing with a separate code base for various classes of device helps.
• Organizational Resource Alignment:  When the web site of an organization is viewed by the business to be a single project across all device classes, it is more difficult to justify the resources needed to maintain multiple experiences.  When seen as a single project, prioritization of features that are critical to one and immaterial to the other often find themselves on the board room floor.  After the lost efficiency from internal battling over top billing, either one channel wins at the expense of the other(s), or they all suffer for splitting resources to the point that they are insufficient for any channel.  For organizations that simply lump mobile in with the web team, it is often the case that these teams are severely under-resourced for the task at hand.  It does not create an environment conducive to long term success.
• Difference of Skill Sets:  A mobile site designer or developer must stay on top of a different skill set when compared to desktop web developers.  There are mobile specific tags and mark-up to be considered, and new devices with new capabilities are hitting the market all the time.  It is a specialty.  Instead of IE vs Firefox vs Chrome and all the quirks to overcome, there are a lot of device-quirks unique to mobile.  Design and coding priorities are different for mobile versus desktop versus tablet.  Allowing these specialties to grow in your organization rather than blending the accountability across a whole team will make for a better product in the end.

As mentioned above, there are a number of ways to workaround many of the issues above.  Some really smart people have come up with a number of clever bits of code, and they are very useful.  Learn and use them.  However, keep in mind that every bit of code sent to a device is a tax on the experience.  By segmenting the class of device, developers can eliminate major sections of code that are irrelevant to the requesting device in advance, addressing much of that logic before before a page is even called.

While exploring emerging methodologies for tackling mobile web development (and let us be clear that all methodologies on this topic are still very much emerging), there are three themes that come up quite often:  One Web, Mobile First, and Responsive Web Design.  If you are in the business of mobile web, all three of those links should be mandatory reading.

Briefly:

One Web opposes the idea of separate “mobile” and “desktop” versions of a site and more broadly advocates that any web page should have just one set of HTML available at one URL.  Each page should be built with the intelligence to be effectively rendered by any standard browser, regardless of device type. 

Mobile First is the practice of stripping a design to its most basic form for the small screen first (based on the explosive growth and importance of these devices) and then building up from that foundation to serve other devices on demand. 

Responsive Web Design is a framework concept to design web pages that float, adjust, and adapt to different  screen sizes in order to produce a single page that renders well on a variety of devices.

These concepts are not mutually exclusive.  I personally support the hybrid Mobile First Responsive Web Design, on which, the book has not even been written yet, but you can bet it is in the works.  These themes are natural companions.  While Mobile First may have initially been conceived of as a design practice, it turns out that it makes a lot of technical sense too as CSS3, HTML5, and JavaScript together provide some slick ways implement this practice within the Responsive Web Design framework.  It effectively reverses the original concept of Responsive Web Design from one of graceful degradation to one of progressive enhancement.

Personally, I do not fully support the concept of One Web.   I do believe in one of its guiding principals, though.  A URL should take a user to a version of a page optimized for the requesting device.  The site should be smart enough to correct (or redirect) when the requested URL and the device calling it do not match, and the user should not have to see any of this.  There are a number of different ways to potentially achieve this.  I think alternate URLs can be used as one possible tool to flag different experiences if done properly.

When built intelligently, with content abstracted from presentation, a single back-end can still serve multiple device experiences without a lot of unnecessary replication.  For the multiple-URL-for-the-same-content issue, this is not a dilemma unique to mobile, yet the Internet still works.  Some sites use slight URL variations to trigger different branding, to load geography-specific content, to change language, to signal a particular affiliate partner, or sometimes in order to track sessions.  It is a fundamental characteristic of the Internet, and while there are some ways to implement it that may be better than others, multiple URLs for the same content is not necessarily an indicator of poor design.  Google will also respect canonical references to fix this for purposes of SEO.

For me, One Web is a “nice to have,” but it is not realistic for most organizations or applications. In fact, there are a few key reasons for why it is better for most sites to separate their “mobile” and “desktop” (and possibly even “tablet”) experiences.

I’ll cover that in my next post.