Device Detection. Technical Overview. Introduction

(1)

Device Detection

Technical Overview

Introduction

As a technique for developing websites that work well on multiple devices, Responsive Web Design (RWD) needs no introduction. RWD primarily deals with client-side information. It makes layout, and in some cases, content decisions based on information determined when the webpage is delivered to the requesting device. While this provides significant steps forward in enabling developers to build a single site to work across all devices, it also brings with it some challenges.

Combining RWD with server-side components - a technique sometimes referred to as “RESS” 1_{, can} provide accurate profiling of connecting devices, making it easier to build mobile solutions that are optimized for both device and speed. With RESS, you can push much of the heavy-lifting associated with rendering the site from the device to the server. That way, a site can begin adapting before it even hits a visitor’s browser, bringing with it performance, quality and targeting benefits.

Device Detection from Netbiscuits is a form of RESS, comprising a device library and enterprise-class device detection and enterprise-classification services. It enables web developers to access and utilize different device and browser feature tests in order to systematically discern browser specifications, capabilities and contextual information. The service captures and provides details relating to browser type and version, device type, operating system, input methods supported and detailed HTML5, JavaScript and CSS3 feature support. This information can then be used to efficiently shape targeted user experiences.

(2)

How does it work?

A typical usage scenario is as follows:

1. The visitor’s device requests brand website (sends HTTP Request to a server)

2. The Web Application on the server receives the HTTP request, and in the background triggers a detect call to the Netbiscuits Device Detection service (passing the HTTP request)

3. The service receives the call, detects the device, reads the device information from the database, and sends it back to the calling Web Application. Included in the response are the JavaScript snippets to be used by the Web Application for client-side detection

4. The Web Application receives the device data and can then:

• Integrate the provided JavaScript code to the response, and detect dynamic parameters on the client side (which means Device Detection provides you with combined server-side and client-side detection)

• Make decisions based on the data, e.g. provide specific content, leave out content, include or exclude features such as streaming video or image gallery

5. The Web Application delivers the adapted web page to the device based on the device information, server-side and client-side detection, as required

(3)

Example scenarios for Device Detection

1. The lowest common denominator?

Let’s assume the developer wants to build a simple page, holding a form that collects the email address of a user. A popular and current way of doing so would be the following:

<!DOCTYPE html> <html>

<body>

<label for=”email”>Email:</label> <input type=”email” name=”email” required placeholder=”[email protected]”/> <input type=”submit” value=”OK” /> </form>

</body> </html>

However, input-type email, the placeholder attribute, and the required pseudo class have been introduced only with HTML5, and many browsers don’t support it. In this example, you can achieve the same

functionality with a combination of HTML (4.01) and JavaScript.

<!DOCTYPE html> <html>

<body>

<label for=”email”>Email:</label> <input type=”text” name=”email” />

// Code for email validation [...]

// Code for checking if the email

input field is not empty [...]

// Code for setting the placeholder

[...] </script> </body> </html>

However, this is clearly more resource intensive than the HTML5 solution (JavaScript execution generally costs more processor time than built-in browser features), and more prone to error.

So you’re facing the following dilemma:

• Do it the smart HTML5 way, and accept that the features won’t work for many browsers/devices

• Or do it in the “lowest common denominator” way, which will probably work on most devices, but means you don’t benefit from the features that state-of-the-art browsers do have

But with Device Detection, you can make sure that the best solution is used for every device.

A simple example in Java (JSP) could look like this: <%@ page language=”java”

import=”com.netbiscuits.dcs. detection.domain.DeviceProfile, com.netbiscuits.dcs. detection.service.Detection” %> <%

Detection detection = Detection. getInstance(); DeviceProfile dp = detection. detect(request); boolean supportsMyFormReqs = dp.getBooleanValue (“BrowserHTML5FormsInputTypeCanEmail”) && dp.getBooleanValue (“BrowserHTML5FormsOtherCanPlaceholder”) && dp.getBooleanValue (“BrowserHTML5Forms ValidationCanRequired”); %> <!DOCTYPE html> <html> <head>…</head> <body>

<label for=”email”>Email:</label> <% if (supportsMyFormReqs) { %>

<input type=”email” name=”email” required placeholder=”[email protected]”/>

(4)

2. Hotfixes

Code should always be as clear and simple as possible. More code generally means more complexity. However, sometimes adding special code - at least on a temporary basis, is the best option available to address a particular problem. Especially when dealing with the different characteristics of various mobile platforms that are constantly being updated.

Let’s have a look at a fictional sample site. http://m. commerce.com is a mobile e-commerce portal with a heterogeneous user base. Stability of the site is crucial because it’s a sales channel, so any downtime impacts revenue directly.

Based on the original requirements, the development team has chosen to integrate one external

JavaScript library that offers several useful functions. They have also encapsulated their self-programmed JavaScript functionality in to one JavaScript file. The site has been tested on a wide range of devices with very good results. User feedback is also good. Now imagine a new update of Android™ launches (let’s say Android 4.4), and suddenly the users of HTC® devices running Android 4.4 are having severe issues, while other users do not see any problems. The management is demanding an immediate solution, since HTC users make up 8% of the overall user-base. After a first analysis, the development

<%@ page language=”java”

import=”com.netbiscuits.dcs. detection.domain.DeviceProfile, com.netbiscuits.dcs.detection. service.Detection” %> <%

Detection detection = Detection. getInstance(); DeviceProfile dp = detection. detect(request); %> <!DOCTYPE html> <html> <head>

<% if

(dp.getStringValue(“Device. Vendor”).equals(“HTC”) &&

dp.getStringValue(“Device. OperatingSystem”).equals(“Android”) && dp.getStringValue(“Device. OperatingSystemVersion”).equals(“4.4”)) {

%>

<input type=”text” name=”email” />

<% } %>

<% if (!supportsMyFormReqs) { %> <script>

// Code for email validation [...]

// Code for checking if the email

input field is not empty [...]

// Code for setting the placeholder [...] </script> <% } %> </body> </html>

team find a potential hotfix, but now have the following dilemma:

• On the one hand, they cannot predict what impact the hotfix potentially would have on other devices/platforms, while thorough testing would need several days

• On the other hand, the issue has to be fixed as soon as possible, since management is very concerned about the potential impact of lost revenues

Usually, some sort of compromise would be chosen: the fix would be rolled-out on a test system, and the most important functions of the site would be tested. After that, the fix would be rolled-out to production, and everyone would hold their breath hoping that no critical issues have been overlooked.

The better solution would be to use Device

Detection. Once you’ve completed your server-side installation, implementing this code will activate server-side decision making based on the requested parameters. The team can then apply the fix only for the devices or device groups for which it’s needed:

(5)

About Netbiscuits: Netbiscuits is a global leader in mobile analytics and device detection. Netbiscuits delivers compelling analytics and device detection products to help companies achieve increased reach and performance, while improving conversion and customer engagement. Our cloud software records over one billion unique page impressions a month, serving global brands such as eBay, Coca Cola, MTV, BMW and T-Online. Catalogued and quality-assured through manual testing since the year 2000, we have the world’s most accurate and complete device library. This library contains detailed device feature capabilities, and includes over 7,300 device, 157 operating system and 343 web browser profiles. The Netbiscuits technology features unique server-side and client-side detection, giving companies access to the contextual information of web visitors such as location and connection speed, to create exceptional mobile

experiences for every connected device.. For more information, please visit: www.netbiscuits.com

Conclusion

Adapting your content, layout and functionality to the increasingly varied devices and contexts that visitors are using online today can have a positive impact on reach, engagement and conversion rates. By moving a large proportion of processing to the server, you can achieve significant impact on page performance, and address some of the challenges of building using Responsive Web Design.

The development team could roll-out this hotfix with minimal risk, since the fix will only get delivered to a distinct group of devices. The team then has enough time to work on a sustainable long-term solution, which ideally would result in the same code for all devices.

It could be argued that the detection of HTC devices running Android 4.4 is also possible by directly checking the user agent string of the requesting device. Unfortunately, these user agents are often ambiguous, i.e. sometimes there are many completely different user agents for identical

devices, sometimes information on the OS is missing, and sometimes you can only find information on the OS, but no clear information on the vendor or model. To make matters worse, user agents often change even with minor OS releases. As future generations of Android 4.4 evolve, you will probably have to adapt detection again. For this reason you’re far better off relying on a mature device database, that is managed and maintained by the vendor.