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.
