Users expect to be able to use and bookmark a website by name—always the same name, regardless of the device used to reach and view the site. From a user’s standpoint, a site is a site regardless of which device is being used to reach it. The code that backs up the site should be smart enough to detect the requesting device and intelligently serve the most appropriate markup.
There are several ways to achieve this goal, and at least three realistic scenarios.
Distinct Sites for Mobile and Desktop
Modern websites are built around the typical size of a desktop or laptop monitor. In fact, until the advent of iPhones, web developers rarely considered the need to fit web content into different sizes. Now, however, establishing an effective presence on mobile devices is a necessity. Just because your websites can be accessed by smartphones and tablets doesn’t make them effective. To provide an effective experience, you must optimize your sites for specific classes of devices—typically, smartphones and tablets. For quite some time, it seemed that distinct “m”-sites were a good-enough solution. For example, the website at www.somecompany.com was available in mobile-optimized form using the URL m.somecompany.com. In terms of development, the two sites are completely different; they were projects that simply shared some portions of the back end.
With a little extra effort in the web server infrastructure, you can set up automatic redirection based on the requesting user agent. In this way, users who bookmark the www site are silently redirected to the m-site if they happen to be using a mobile device.
This scenario is probably the most common today—and certainly the cheapest, in terms of both money and code. But it’s also losing appeal every day. The net, binary, separation between desktop and mobile is destined to last for no more than a few months. Mobile has exploded into a myriad of fragments of various screen sizes: smartphones, tablets, mini-tablets, pad-phones, smart TVs, and large screens. A plain m-site doesn’t work well anymore because the problem has morphed into something else.
One Site Fits it All
As a developer, you may remember very well how hard it was a few years ago to ensure that pages could display consistently across multiple browsers. The problem has not disappeared today but it was much tougher to solve some eight years ago. This “browser hell” originated because developers were forced to try to craft markup to support each browser user agent. Over time, the browser-detection approach clearly proved to be less than ideal.
Today, many propound an orthogonal approach called feature detection instead that greatly simplifies code. Feature detection is based on the idea that you can check via code whether the browser supports a specific feature you’re interested in using, and proceed to generate appropriate markup based on the response.
Feature detection combined with CSS media queries and proportional layout brought the state of the art to Responsive Web Design (RWD). The net effect of RWD is that you design the website once, but for multiple screen resolutions (mostly taking width into account). The HTML template you create ensures that the site renders well regardless of the screen width.
Because screen width is the primary concern, users see the same view displayed whether the site is viewed on a smartphone or in a resized desktop browser window.
RWD is entirely based on CSS—and CSS is about layout, not about logic. CSS helps in flowing content blocks vertically rather than horizontally, and in hiding blocks that are unnecessary at certain points in the application. So while RWD helps with the view, you can hardly provide a truly optimized experience to smartphone or tablet users in all business scenarios.
RWD is still excellent with sites that are essentially read-only, such as portals. But for sites that implement complex workflows, such as e-commerce or booking applications, you probably want users to experience a set of pages specifically designed for their particular class of device—again, primarily smartphones and tablets. In addition, RWD isn’t set up to minimize the amount of data being downloaded on a smartphone—and that lack shows.
Still One Site, but Multiple Views
The mobile revolution brought a new family of products, called device description repositories (DDR). A DDR is a database that contains information about the known features of a device. The device is identified through its user agent, which exposes a user agent string that identifies the device. That user agent string is then used like a key to find a matching database row that contains the capabilities of the device. The DDR database exists on the server-side.
The server-side code used to generate HTML views queries the DDR, passing the detected user agent string. By doing so, the web application performs server-side feature detection and gets the information it needs to serve a truly optimized and device-specific page.
This approach is much more effective than RWD for two reasons. First, it gives you a lot more control over what gets downloaded. Second, it lets you have differing layouts on a per-device basis rather than simply using different styles. The main downside of the DDR approach is that the information in the repository is—for the most part—not free. The most commonly used DDR is WURFL (http://www.scientiamobile.com/) which is the DDR that large organizations such as Google and Facebook use for their mobile sites.
If you’re currently building two or more versions of your site, or if you’re simply using RWD and/or “m” sites to fulfill your customers’ needs, you should consider building one solution that uses DDR, because it lets you “future-proof” your sites by reacting to specific device capabilities, and it’s extensible for devices that will appear in the future.
You can find a much more extensive discussion of modern mobile site architecture in my book Architecting Mobile Solutions for the Enterprise.