A couple of years from now, web site will either be easy to consume from within any mainstream devices or else it will experience a significant drop in traffic. Note that, I took the precaution of writing “mainstream devices” here instead of using more specific terms such as tablets or smartphones. Nobody really knows exactly which devices may become of wide use in a couple of years, but whatever devices may come up, web sites will need to be ready to support them.

How could one go about implementing a way of reliably detecting the device that is accessing the website? Developers will be reluctant to embark on painfully creating their own detection engine which may subsequently become a nightmare to update and maintain. This is something that seasoned developers have already experienced with the browsers war in the late 1990s when it was a hopeless task to make a plain site look the same, or rather nearly the same, across multiple browsers. After this experience, Responsive Web Design (RWD) was generally welcomed because it seemed to be the right tool to serve adapted content to just about any device. RWD might really be a good solution we all hope for, except that it deliberately works by completely ignoring the device.

In the previous articles of this RWD mini-series, I outlined what’s good and bad about RWD. This article presents an alternate solution. More specifically, the article presents an approach that builds on top of RWD principles and expands them to a wider perspective. The technical details of the resulting solution are more or less those discussed in this article–Multiple Views and DisplayMode Providers in ASP.NET MVC 4-and refer to ASP.NET MVC display modes.

The Form-factor Concept

Today “form-factor” refers to a device’s size, shape, and style and is a convenient synonym to encompass terms like “class of device” or device profile. When you refer to the form-factor of a device you assume that it includes specifying what type of device it is such as a tablet, a mini-tablet, a smartphone, a legacy phone, a feature phone (something in between old dinosaur phones and smartphones), a PC, a smart-TV / Xbox, a wearable device.

Beyond Feature Detection

New devices and browser builds appear nearly every month. Should a web developer cope by maintaining a list of browsers and related features? It would take too much effort to build and maintain such a database purely for effective device-detection. Anyone who attempts the task could well end up marketing it as their main business. They won’t be the first, since a few companies are already providing device databases, and related API, as a service. They made a true business out of recording the features of individual devices and just focus on that. For other companies, the dilemma is whether to buy the services of some device description repository (DDR) or build their own.

At first it seemed that feature detection would render this unnecessary. Interest around feature detection arose with the advent of HTML5 and the growing demand for a way to serve the right HTML markup to browsers. HTML5 standards, in fact, are still a moving target and no guarantee exists that the latest browser version is installed, so someone came up with the idea of checking the HTML5 API before using it. Some HTML5 tags can be silently used in combination with older HTML fallbacks but HTML5 frameworks (i.e., local storage) need some preliminary check to avoid JavaScript runtime errors. Most HTML5 API can be easily checked via JavaScript-local storage, canvas, geolocation and also the events raised by features like drag&drop and touch.

Feature detection simply tests for the features you want to use. And it is smarter, faster and more manageable than checking browser versions and it doesn’t require you to know exactly what each browser version supports. Script libraries help a lot with feature detection; popular libraries for feature detection are jQuery and Modernizr.

It is unfortunate that feature detection is not completely reliable because it relies on code and can only use the information that browsers expose. Sometimes it happens that the browser claims it supports a feature but in the end the browser just lies, or support is only partial; perhaps implementation is poor or buggy. More than everything else, though, feature detection doesn’t strictly apply to devices. Feature detection can tell you whether the browser can perform certain tasks or let you code against a certain API. It doesn’t tell you anything about the device. To write really device-friendly sites, at some point, you need to know about the capabilities of the underlying device. Feature detection is alternative to browser detection; but not to more general device detection as it is required today.

Feature detection is the right solution if you want to implement a feature regardless of the underlying browser and if you want the site to look the same on all browsers. By the same token, feature detection is not the complete solution if you want provide the best possible experience for users connecting through a given type of device.

Form-factor Detection

Who can reliably tell you about the form-factor of the requesting device or answer questions like “is this device a tablet”? The homemade approach of parsing the user agent (UA) string works unsatisfactorily because the agent strings are, in practice, often an inextricable mess of strings, substrings and rules. Yet, user agent sniffing is the only way to try to make sense of the identity of a device.

More professional user-agent sniffing is essentially a query against a database of user agent strings. In the simplest-ever implementation, you have a key/value dictionary of UA strings where the key is the UA string and the value is some serialization of related device information. Today, databases of UA strings employ a lot more sophisticated storage mechanism. Such databases are called Device Description Repositories (DDR).

A typical DDR such as WURFL, DeviceAtlas or 51degrees, can tell you about the capabilities commonly associated with that device. A DDR “knows” whether the browser mounted on that device supports streaming or can display animated GIFs or CSS gradients. In addition, a DDR knows the operating system and version of the device and can tell you whether that device is considered a tablet, a smartphone or whatever else.

The list of Form-Factors that a web site intends to support serves a similar purpose to the list of visual breakpoints that you define within an RWD solution. As the term ‘mobile-first’ suggests, the HTML grows with the available space: You start with a view that fits into small devices and then extends the HTML to show more content and rework basic functions as the available space grows. Each breakpoint where you switch layout (by switching CSS over the “same” HTML) is a visual breakpoint in the RWD jargon. That’s precisely what the “form-factor” concept does, except that it takes into account much more than just the screen width.

Access to information about device capabilities comes from knowing and observing what a device can or cannot do. Information about platform and firmware, instead, comes from the user agent string. Usually, browser and device vendors update the user agent string when new firmware or just an update is installed. For this reason, the user agent string contains reliable and up-to-date information about the platform. Neither the user agent string nor a single capability can tell you whether a given device is a tablet or a smartphone. The form-factor results from the comparison of multiple-and device-specific-capabilities. The list certainly includes screen width but it is not limited to that and includes operating system, touch capabilities, and maybe more.

Consuming form-factor Information

In much the same way you define a different CSS for each visual breakpoint, you may have a different HTML view for each form-factor. From an implementation point of view there are two issues to face.

• How you determine the form-factor?
• How you switch between different views?

To get the form-factor you use a DDR. A DDR consists of a database with device information and an associated API. The API typically works by taking a user-agent string and returning an object with device information. DDRs require a license mostly because of the costs associated with the provision of the service. Nearly all of them, though, provide some free offering that is enough if you’re only interested in the form-factor. The DDR API can be available on-premise, through the cloud or even as a JavaScript plugin. WURFL-the de facto standard DDR-for example just offers all these options and for a variety of programming platforms beyond ASP.NET.

Once you know the form-factor, the next problem is to define distinct views and serving them appropriately to devices. Who does the routing work?

One option is to use ASP.NET MVC and display modes. In this case, you add a display mode for each form-factor and create multiple Razor views such as index.cshtml, index.smartphone.cshtml and index.tablet.cshtml. The form-factor suffix is up to you, as is the number of form-factors. A display mode contains a Boolean expression that processes the entire HTTP context, including the user agent header. Based on these expressions, the underlying engine detects the right view and serves that to the user. Views might be expressly done for each Form-Factorand each view is independent, meaning that it can use different CSS, JavaScript and HTML.

Is this the problem? Surely, there might be situations in which it is also awkward to use display modes. It could, for example, be a pain in the neck to use display modes the RWD way. If you develop all views at the same time, and all views are nearly the same, but merely adapted to a smaller screen, I agree that you are likely to end up doing the same work once for each form-factor. It’s even worse if views are JavaScript-intensive such as when you are using AngularJS or similar libraries.

Display modes are helpful if you have completely different views and use-cases to create. Compared to having just different sites (like an m-site), display modes are better because it’s one site and one project. At the same time, independence of views from one another allows you to focus one form-factor at a time in no specific order.

Some DDRs-specifically WURFL-also offer a JavaScript version. In particular, WURFL.js, available at http://wurfl.io, is free for everybody to use. Once referenced in the HTML page, all it does is to check the user agent and inject a JavaScript object in the DOM with a few items of data, most notably the form-factor string. This is immensely helpful in JavaScript-intensive applications that can use this piece of information to more effectively design the user interface and adjust or create the user experience from scratch in a way that is closer to the user’s expectation for that device. In this way, a 800px resized browser window is treated differently from a tablet window.

Summary

RWD is a powerful approach that was created to improve the rendering of web sites. It was not born to build multi-device websites. As RWD is quite smart, it can be easily adapted to work with devices and build multi-device experiences. In most cases, this adaptation just works. As developers, we’re called to solve concrete problems with the additional burden of being able to provide demos and prototypes quite soon. If you can solve the problem by getting a readymade responsive template and are good enough with CSS to achieve the layout you expect, by all means use RWD.

RWD, though, has some hidden costs and little known side effects that may hit you unexpectedly. The approach you take depends on the application. The industry is full of case-studies where RWD emerges as the winner and as many examples of companies that successfully opted for using specific views. (A prominent example is LinkedIn.)