July 2012

Volume 27 Number 07

Cutting Edge - Mobile Site Development, Part 2: Design

By Dino Esposito | July 2012

There are a few myths about mobile site development that mostly derive from the idea that a mobile solution is a spin-off of an existing desktop Web site. I think the term spin-off is quite appropriate to describe the relationship between a mobile and a desktop Web site. The crucial issue concerns the details of how you actually spin the mobile site off the full desktop site.

You want to offer your users the best navigation experience for the device they have—whether it’s a regular PC, a smartphone, a tablet or an old-fashioned cell phone. (I’m skipping over an emerging family of large-screen devices such as smart TVs, which will require their own ad hoc rendering in the near future.) You also want to present users with a set of pages that can be best viewed on the requesting device. How would you select the markup that best fits a given device? In my opinion, this is a sore point and deserves a bit of attention and analysis to keep you from believing the myths and ignoring real-world conditions.

The One-Site-Fits-All Myth

Most developers recognize the need to have a mobile and a desktop Web site that look different from one another. Screen sizes are different, computing power is different and use cases especially are going to be fewer and largely different in a mobile site. Nevertheless, the idea of building just one Web site that automatically adjusts to different resolutions is attractive to many developers. But it also may be a dangerous route with more cons than pros. Realistically, the pro/con balance is going to depend on the nature of the application: the more sophisticated the site, the more cons and the fewer pros. What does it mean, exactly, to have a single site that adapts to multiple devices? Many developers have bad memories of when—only a few years ago, if not still today—building a Web site was a matter of extricating yourself from the mess of different (desktop) browsers and different rendering capabilities. For this reason, most developers welcome the idea of a single site that users can visit with any device (laptops, tablets, phones, e-readers, smart TVs and so on), but with a different experience. 

The point is that with desktop browsers most of the differences are in the rendering space. Mobile devices, instead, add one more dimension to the problem: different capabilities. So the goal should be to build a Web site that automatically serves the most appropriate experience to different devices rather than an over-emphasis on the most appropriate rendering of the content.

Sound like a subtle difference? Well, client-side adaptation versus server-side adaptation of mobile content is an open point these days. 

 To me, the idea of just one Web site that serves the same content to which the browser adjusts according to the device being used just doesn’t work as a rule—but it might work as an exception. The one-site-fits-all myth builds on top of the browser capability of dynamically selecting the most appropriate CSS stylesheet given some physical device characteristics. Let’s find out more.

CSS Media Queries

Introduced with CSS3, media queries are a browser feature meant to simplify the design of sites that might be consumed through devices of different screen sizes. It should be noted that the term device in this specific context also includes laptops and desktop PCs. For this reason, the screen size might range from the 24 inches of a desktop monitor to the 3 inches of most smartphones.

The idea behind CSS media queries is that you create one Web site with a single set of functions and then apply different CSS styles to it by loading a different stylesheet for different media. The great improvement brought by CSS3 is that the screen page medium now can be restricted to all devices that match a set of given rules. Here’s an example of a media query:

<link type="text/css"
  rel="stylesheet"
  href="downlevel.css"
  media="only screen and (max-device-width: 320px)">

Once placed in a Web page (or ASP.NET MVC view), the preceding markup links the downlevel.css file only if the page is viewed through a browser with a width of 320 pixels or fewer. Using a few of the preceding elements lets you optimize the rendering of any page to devices of different screen size. Nicely enough, the stylesheet rule is applied dynamically and also adjusts the page content when the user resizes the browser window on the desktop.

It should be noted that in CSS media queries, there’s no explicit check on the type of browser, whether mobile or desktop; all that matters is the effective width of the screen. However, when you use a media query to filter out browsers with a width larger than 320 pixels, you’re surely selecting all mobile devices and cell phones with that screen size.

The keyword only in the media query should be added for the sole purpose of hiding the media query statement from browsers that don’t support media queries. These browsers, in fact, don’t understand the media type and blissfully go ahead with their rendering. It’s a common thought these days that by simply adding media queries to a site you make it ready for mobile clients. My opinion is slightly different. CSS media queries help make the page content more mobile-friendly, but they don’t help in any way in optimizing the mobile site for other critical aspects such as the number of HTTP requests per page and the amount of data downloaded.

Furthermore, media queries can discern only a limited number of browser properties. The full documentation about media queries can be found at bit.ly/yOuW7q.

CSS media query properties tell you something about the device—but not all you may need to know. For example, you have no clue about the OS, whether the device is mobile or not, whether it’s a tablet or a smart TV or perhaps a bot. Likewise, with CSS media queries, you have no idea if the requesting browser supports Asynchronous JavaScript and XML and Document Object Model manipulation, how it deals with HTML5 and jQuery Mobile, or which type of markup it prefers.

Being a CSS feature, media queries are processed by the browser’s CSS subsystem. It turns out that media queries can only select a set of element styles that hide or resize some elements that are either too big or that can be reduced on a small screen. With CSS media queries, you still pay the costs of downloading and keeping these elements in memory even when they aren’t displayed. You can use some JavaScript in the pages to programmatically download or configure images. In this way, heavy elements can be managed in a more optimized manner. This extra work, however, is up to you.

Last but not least, media queries require a browser that supports CSS3. This means CSS media queries work great on most smartphones but not on older devices—and not even on Windows Phone 7. You can opt for an all-browser solution for media queries by getting a jQuery plug-in from https://docs.jquery.com/Plugins/Authoring. However, in this case as well, there’s no guarantee that the mobile browser where you might be using this plug-in can really run jQuery.

Overall, CSS media queries are not a technology specifically aimed at mobile development. However, the flexibility of CSS media queries makes them compelling to use to serve different devices with a single codebase. They might be a solution in some cases, but CSS media queries are not the way to go for just any scenario.

Multi-Serving

The server-side route to mobile development is based on the idea that the Web site receives a request, gets the user agent and uses that information to figure out the effective capabilities of the browser. Next, armed with that knowledge, the Web site intelligently decides what would be the most appropriate content for the requesting device.

How would you find out about browser capabilities? At present, the most effective strategy seems to be using a Device Description Repository (DDR)—namely a database that stores nearly all possible properties of nearly all devices and that is constantly updated as new devices hit the market. In what way is a DDR different from the ASP.NET Request.Browser object? In a way, the Request.Browser object can be seen as a simple DDR that contains good information about desktop browsers but not particularly accurate information about mobile devices. 

The number of different models of mobile devices is in the order of thousands and growing. The properties that a developer can find interesting for each device profile in a particular use case might vary significantly, but if you take the union of all of them you easily reach a few hundred. What options do you have today for getting accurate device information?

The DDR called Wireless Universal Resource File (WURFL) is an XML database that currently contains more than 15,000 profiles of mobile devices and matches half a million user agent strings. Each profile contains more than 500 capabilities. WURFL is an open source framework released under a classic dual-licensing scheme, AGPL v3 and commercial. WURFL is also available as a cloud service and some basic plans, limited to a few properties, are free. For more information, visit scientiamobile.com. WURFL is not the only DDR out there, but WURFL can be considered the de facto standard. Among other things, WURFL is employed in the mobile platform of Facebook and Google. WURFL has APIs for PHP, Java and the Microsoft .NET Framework, and it plugs smoothly into ASP.NET applications via NuGet.

As far as the ASP.NET platform is concerned, another interesting DDR solution is 51Degrees (51degrees.codeplex.com). 51Degrees originally relied on WURFL as the source for device information, but it has been relaunched recently with a new internal architecture and vocabulary. 51Degrees is a purely commercial initiative, but it offers a free version of the framework limited to four properties: isMobile, ScreenPixelWidth, ScreenPixelHeight and LayoutEngine, which refers to the browser rendering engine. As far as their free offerings are concerned, WURFL and 51Degrees are nearly equivalent, apart from the licensing.

Understanding Wants and Needs

Mobile development is mostly about understanding what your customers want and need. This is a crucial point and is solved when you have a well-chosen selection of use cases. For mobile sites in particular, I estimate that getting a good selection of use cases to implement is the largest share of the work. Beyond this, mobile development requires recognizing that mobile browsing is different. This means that having just one Web site that morphs into different rendering for different devices is your goal, but it won’t be attained free with just the magic of a few CSS files. CSS contains almost no logic, and you probably want to have logic involved in deciding which content to serve to a given class of devices.

In the next article, I’ll discuss how to switch from a desktop to a mobile site, thus delivering two sites but possibly one experience to the user. Later on, I’ll delve deeper into browser segmentation and alternatives to media queries.

Dino Esposito is the author of “Architecting Mobile Solutions for the Enterprise” (Microsoft Press, 2012) and “Programming ASP.NET MVC 3” (Microsoft Press, 2011), and coauthor of “Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2008). Based in Italy, Esposito is a frequent speaker at industry events worldwide. Follow him on Twitter at twitter.com/despos.

Thanks to the following technical expert for reviewing this article: Steve Sanderson