This is the third part of a three-part mini-series on Responsive Web Design.
- Responsive Web Design: the Costs
- Responsive Web Design: The Downsides
- Responsive Web Design: Relying on the Form-factor
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.
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.
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?
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?
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.
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.)