Thanks to larger and larger screen resolution and increasing processing power, the latest smartphones can blissfully display regular websites. But is this really what users want? Typically, regular websites are too rich with information; in most cases, the font is too small and nearly impossible to read. Following links can be as challenging as catching a fly. Sure, users can browse a website using a smartphone, but at the cost of continuously zooming in and out pages and relying on the browser's ability to reflow text quickly and effectively in the actual screen real estate.
Not all websites have a mobile version and not all of them need one. In general, having a mobile site with certain features is part of a company's mobile strategy and relates to the business model and the vision that management has for it. How would you take visitors to your mobile site after it has been deployed to production?
One option requires that visitors explicitly point to a specific mobile website such as m.yoursite.com. Another option is that your website detects mobile devices and automatically redirects them to a mobile site, or to the section of the regular site that can serve content optimized for mobile devices. As a user, I prefer to be automatically redirected to content tailor-made for the device rather than having to type the mobile site URL myself. As an ASP.NET developer, how would you redirect visitors to another site? At first this doesn't seem like such a complex task. Rocket science isn't required, but the devil can be found in the details. Let's find out more.
Detecting Mobile Browsers
The code to write is not complex. You need an HTTP module that intercepts incoming requests as early as possible and parses the user agent string identifying the capabilities of the browser and the underlying device. The problem here isn't writing the HTTP module; the problem is figuring out the information in the user agent string.
Today, an interesting number of ASP.NET sites use a specific framework for browser detection—51Degrees.mobi. You can obtain the framework from http://51degrees.codeplex.com or directly from Visual Studio as a NuGet package. The 51Degrees.mobi framework is based on an HTTP module that intercepts requests and determines a device's capabilities. In doing so, the framework also updates and, in some cases, extends the information in the browser object. If you have NuGet installed in Visual Studio, all you have to do is locate the package in the library manager. Figure 1 shows the window you see from within an ASP.NET project when you choose to add a package reference.

Figure 1 The Visual Studio package list
Installing the package makes some changes to the current project. In particular, a couple of assemblies are added to the Bin folder and, more importantly, a zipped XML file is added to the App_Data folder. This file contains the most accurate up-to-date information about the capabilities of mobile devices. The HTTP module uses this information to identify the capabilities of the requesting device. Note that the 51Degrees.mobi framework doesn't query the device directly; it just attempts to identify the record in the WURFL database that matches the browser's user agent. Any information WURFL contains about the device capabilities is copied into the Request.Browser object and returned to the ASP.NET application. WURFL, an open-source project started by Luca Passani about 10 years ago, matches the browser's user-agent to the corresponding device profile. Because the WURFL database is frequently updated and extremely detailed, the odds that you'll fail with a particular mobile browser are low. By now, WURFL is the de facto standard solution for device recognition. I'll return to WURFL later.
A Look at a 51Degrees-Enabled Project
The key changes the 51Degrees package introduces in your project are in the web.config file. First and foremost, a new HTTP module is registered to capture incoming requests:
type="FiftyOne.Foundation.Mobile.Redirection.RedirectModule,
FiftyOne.Foundation" />
The behavior of the module is driven by settings entered in a custom

Figure 2: Settings in the
As you can see, the framework is quite flexible; allowing you a lot of freedomn setting up things while being unobtrusive with the structure of the site. In particular, the framework provides an optional landing page meant to be the home page of the mobile site or the root page of your site's mobile section. Redirecting every single request might represent an unneeded burden for your application. With the firstRequestOnly attribute you can redirect only the first request. If your pages use relative links, no further redirection would be required after the first. The timeout attribute (set to 20 minutes by default) indicates the time of inactivity after which a new request should be considered again as the first and be redirected.
The flexibility of the framework shows up well in the description of the
firstRequestOnly="false"
devicesFile="~/App_Data/Devices.dat"
timeout="20"
mobilePagesRegex="/Mobile/" />
The package adds to your site a default landing page and operates on each and every request. All pages in your site that match the /Mobile/ URL are treated as mobile pages and ignored by the redirect module. With this code in place, let's see what happens when you visit the site with a few mobile devices.
Testing Devices

Figure 3: Redirected to the mobile landing page from Android and WP7 browsers
At present, you can't easily grab a screenshot of a real Windows Phone 7 device, but I guarantee that the real experience is exactly the same as the emulator demonstrates.
Figure 4 shows what happens when using an iPad. Note the reported values of properties like IsMobileDevice and IsTablet.

Figure 4: Redirected to the mobile landing page from an iPad
The identification of the device is definitely accurate. In particular, the screenshots reproduce the output generated by the code Figure 5 shows.
Figure 5: Code that generates the screenshots Figure 4 shows
Some attributes of modern devices are missing in the public interface of the HttpBrowserCapabilities class, an instance of which is returned by the Request.Browser property. Aware of this, designers of the HttpBrowserCapabilities class added an indexer property that 51Degrees leverages to add extra information that the WURFL database offers and that isn't reflected by the public browser capabilities API. Attributes like is_tablet and pointing_method just demonstrate the usefulness of the indexer. Another interesting WURFL attribute you might want to check is device_os:
51Degrees.mobi is a framework through which you can easily control the behavior of the site when accessed from a mobile device. The framework serves the purpose of automatically redirecting users to mobile content. But you could let users decide whether a redirect will occur.
Some mobile browsers have a nice feature that lets users decide about the user agent string the browser sends out. Figure 6 shows how you can enable (or disable) the mobile user agent on an Android device's native browser.

Figure 6: Enable or disable mobile versions of web pages
IE on Windows Phone 7 offers the same capability. Currently, I'm evaluating the usability and implementation of a feature that would allow users to control a redirect on a per-site basis, for example through a popup message and saving preferences to a cookie.
What's WURFL?
To explore the information that WURFL can serve you, you can read the source XML file—not really a recommended experience, although sometimes necessary. It's easier if you go to www.tera-wurfl.com/explore, and much better if you follow the link with a mobile device.
You can freely incorporate WURFL in any of your applications and components, regardless of their personal, open-source, or commercial nature. Of course, a requirement is that any modification you apply to the file is returned to the community.
The Best Practice
The problem is finding the best way to let users know about mobile content and serving that. A common choice these days is automatically redirecting a user to the mobile content. For this to happen, it's critical to correctly identify the device. In this regard, WURFL plays a fundamental role because it's the most accurate mobile device database. How would you integrate WURFL? You can do that manually by leveraging the public WURFL API, or you can resort to platform-specific frameworks that do that for you.
Dino Esposito, author of Programming Microsoft ASP.NET 4 and Programming Microsoft ASP.NET MVC (Microsoft Press), is a trainer and consultant specializing in web and mobile architectures and effective code design principles and practices. Follow Dino on Twitter at @despos.