June 2012

Volume 27 Number 06

Cutting Edge - Mobile Site Development: Markup

By June 2012 | June 2012

As more and more devices are used to browse the Web, having a mobile-optimized Web site is becoming a critical factor for companies. Let’s face it: Even with most modern smartphones, browsing a desktop site is quite problematic. You need pan and zoom to make sense of content and follow links. Doable, sure, but not a fantastic user experience.

I use my smartphone to browse desktop sites, and I often prefer to see the full version rather than the mobile version when available. I do this for one key reason: Mobile sites often aren’t as well designed as desktop sites. As a frequent user of a site, you develop certain expectations. You expect to find all of them met by the site regardless of the medium you use to reach the site. If you reach the site with a mobile device, you ideally expect the same level of service, but targeted to your current status—that of a mobile user, possibly on the go, possibly hurried and possibly using a poor connection.

This is precisely the challenge that architects and developers of a mobile site face. What’s most problematic with a mobile site isn’t necessarily the implementation of functionalities. A mobile site generally has fewer functions and actions per page than a desktop site, and fewer lines of code means fewer problems. However, to offer a great user experience, commonly requested functionalities are required even more urgently than for a desktop site. Ensuring a great user experience on mobile devices can be challenging, and often a team has to resort to extremely clever coding and design solutions.

In addition, mobile sites might need to serve a wide range of different devices. If dealing with different desktop browsers scared you until a few years ago, think about the mobile space, where the different device profiles you might be dealing with are in the order of thousands. (This doesn’t mean, however, that you must arrange for thousands of different versions of a page—you just reduce these thousands of device profiles to a few classes of devices that you handle differently.)

This article is the first of a series in which I’ll try to approach mobile site development using a perspective that isn’t primarily focused on technology. I find that too often mobile site development is associated with specific frameworks and their solutions, without spending much time thinking over use cases and restructuring of the content. In this article I’ll start from the basics—the mobile markup.

Browsers and the Viewport

By default, most mobile browsers today render pages in viewports far larger than the actual device screen sizes. The actual viewport width varies with the browser, but it’s always close to 1,000 pixels. For example, it’s known to be 980 pixels in Safari for iPhone and Internet Explorer 9, and 800 pixels on Android WebKit. As a mobile developer, your first task should be understanding the role and origin of the viewport. Figure 1 shows how mobile browsers use the viewport.

Figure 1 How Mobile Browsers Use the Viewport

The viewport is a fixed-width area where the browser renders any content. The viewport size is not necessarily related to the physical screen size. This isn’t a big deal in a desktop browser, but it becomes an issue on the significantly smaller screens of mobile devices. Browsers tend to render pages in whatever their internal viewport size is. When it comes to display, however, they zoom out the viewport so that the whole content fits in the real screen size.

The net effect is that, as a user, either you need to scroll horizontally and vertically to reach content or you need to zoom in to make content readable, and, more importantly, allow yourself to follow links. An excellent resource to learn more on internal implementation of viewports in browsers is at bit.ly/bZYlKb.

Viewport and Markup

In the beginning of mobile site development, the markup used wasn’t the same as in desktop sites. Over the years, we moved from Wireless Markup Language (WML) to compact HTML (cHTML) to extensible HTML (XHTML) for mobile. In all of these cases, a distinct Multipurpose Internet Mail Extensions (MIME) type was served to the browser. Based on that, the browser could figure out what type of content it was going to receive and render it accordingly. With the advent of the iPhone it was clear that the capabilities of mobile devices could be compared to laptops, at least for rendering Web pages. But serving the same markup to mobile and desktop browsers raised the issue of different screen sizes and forced mobile users to zoom content in and out as appropriate.

If the same MIME type (text/html) is used for both desktop and mobile requests, the browser can no longer use the MIME type to figure out whether you intend the content to be laid out on a desktop- or mobile-sized viewport. That’s why Apple Inc. introduced the viewport meta tag a few years ago. Now the viewport meta tag is a de facto standard, and any page intended to be a mobile page should have it set. Here’s how you typically use the viewport tag:

<meta name="viewport" content="width=device-width" />

The content attribute of the meta tag is set to an expression where a few properties can be set to ad hoc values. The most important of these properties is width. Browsers use the width property to dynamically set the size of their viewports. You can set the width property to a specific number of pixels or to a special expression, as in the preceding example. In particular, the value device-width indicates the width of the screen in pixels. Note that in this context a pixel is intended as a device-independent pixel or a CSS pixel. On devices with a high density of pixels the browser is forced to rescale, and it might be that a width of 100 pixels covers some 150 or even 200 physical pixels. Figure 2 lists the properties supported in a viewport expression. 

Figure 2 Properties in a Viewport Expression

Some browsers might have extra properties. In particular, Android browsers also understand the target-densitydpi property through which developers communicate the desired screen resolution intended for the page. This might help Android browsers to optimize scaling of pixel-based resources such as  images. The target-densitydpi property can be set to a specific number or to a special value such as device-dpi.

Here’s a more specific way to set the viewport meta tag:

<meta name="viewport"
  content="width=device-width, user-scalable=no, initial-scale=1"/>

The height property isn’t used often. You typically use it if you have elements that are to be placed at the bottom of the screen or in a position dependent on the height of the viewport. Finally, note that setting user-scalable to “no” will disable pinch-and-zoom on that page.

The viewport meta tag is pretty common today, but in the past other meta tags such as HandheldFriendly and MobileOptimized were used by some browsers for the same purpose:

<meta name="HandheldFriendly" content="true" /> 
<meta name="MobileOptimized" content="320" />

The World Wide Web Consortium (W3C) is elaborating a paper to standardize the viewport element. You can read the current draft at bit.ly/AavTG5.

HTML and XHTML Mobile Profile

The ultimate goal of the viewport and other meta tags is to indicate the size of the viewport on which the developer wants the content rendered. You use meta tags if you serve plain HTML markup to mobile browsers. If, for some reason, it’s OK for you to serve mobile markup, you don’t need meta tags, but just a document with an XHTML Mobile Profile (MP) DOCTYPE: 

<!DOCTYPE html PUBLIC
  "-//WAPFORUM//DTD XHTML Mobile 1.2//EN"
  "https://www.openmobilealliance.org/tech/DTD/xhtmlmobile12.dtd">

The MIME type for XHTML MP is “application/vnd.wap.xhtml+xml.” Compared to the expressivity of plain HTML, XHTML MP is a thing of the past because it has limitations in Document Object Model (DOM) manipulation and important areas such as support for CSS and JavaScript.

The current standard that works for most of today’s devices is using HTML with the viewport tag. However, it might be that your site should be open to a really large set of devices, including old devices that don’t support HTML or the viewport tag. How can you address this situation?

As blunt as it might sound, you need some help from special databases that store information about the capabilities of mobile browsers. These databases are known as Device Description Repositories (DDRs). Wireless Universal Resource File (WURFL)—the DDR used by Facebook—has a property called preferred_markup that you can query on the server (for example, from within an ASP.NET application) to determine the most appropriate markup to serve to a requesting device. You can read more about WURFL at wurfl.sourceforge.net. I plan to cover WURFL and other DDRs such as 51Degrees in future columns.

HTML5 and Mobile Browsers

HTML5 is a markup language that modern mobile browsers support quite well—at least for the current state of the standard. This applies to browsers embedded in smartphones (that is, Safari on iPhone and iPad, Android WebKit and Internet Explorer 9 on Windows Phone) as well as external browsers such as Fennec (the mobile version of Firefox) and Opera Mobile.

In particular, you can check out mobilehtml5.org for a thorough comparison of HTML5 support on a variety of mobile browsers. You’ll see that Canvas and SVG support is nearly ubiquitous, whereas input elements—critical on mobile pages—are well supported on iOS 5 but not on current versions of Android WebKit. Local storage, geolocation and multimedia are also nearly everywhere. 

Not That Smart

Too often a mobile site is simply perceived as an offspring of the existing desktop site. So it happens that most of the design is done from the perspective of the desktop site while assuming that the client is as “smart”—or rich and powerful—as a desktop browser. But smartphones aren’t as “smart” as laptops. This large fragmentation is a critical aspect of mobile site development. For this reason, when you start a mobile site project, the first aspects to consider are use cases to cover and devices to target. Any technology you might want to use comes later. In future columns I’ll discuss techniques to identify ad hoc mobile use cases, patterns of mobile development and device-sensitive rendering.

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 experts for reviewing this article: Shane Church and Steve Sanderson