Mobilizing the Mileage Stats app

What is Mileage Stats Mobile?

Mileage Stats Mobile is a reference app developed by the patterns & practices team in order to explore and understand the challenges associated with the mobile web. It is built on top of another reference app, Mileage Stats, which was included as part of Project Silk. Mileage Stats Mobile seeks to augment the original legacy app by providing a mobile-friendly experience while preserving the original functionality for clients that can be classified as desktop browsers.

Mileage Stats itself is an app that allows users to track information about a fleet of vehicles, such as fuel efficiency and cost of maintenance. The legacy experience was intended to provide guidance for building a multi-page web app where the pages are rendered without requiring a postback. (This pattern is commonly referred to as single page application, or SPA.) Likewise, the legacy app highlighted features of modern desktop browsers while still remaining completely functional for older browsers through the use of techniques such as progressive enhancement.

Mileage Stats Mobile differs from its predecessor by focusing on problems that are relevant to mobile devices (unreliable and unpredictable network connections, a diversity of browsers, and so forth). As a result, it also more deeply embraces concepts such as semantic markup.

Follow link to expand image

Please click the thumbnail above for a larger view of the Mileage Stats mobile app map

Let's now examine the process we used to determine the Mileage Stats mobile experience, and how it would map to various types of mobile devices.

We began by identifying the key features and functionality of the Mileage Stats app. This then enabled us to define key experience groupings and indirectly enabled us to define the browsers and devices we would support.

The default app experience

Although Mileage Stats Mobile is a moderately sophisticated app, the base functionality is quite simple. To use the app, users must simply be able to complete a series of online forms: one to add a new vehicle, and the other to add a fill up. The rest of the functionality involves basic display of HTML and static images.

Identifying this baseline requirement resulted in one very simple technology requirement: a modern browser with good HTML 4.01 and CSS 2.n support.

Setting this as a base requirement meant we could (in theory) support an extensive range of devices. It did, however, force us to eliminate certain older and/or less capable devices including legacy smartphones and feature phones with only XHTML MP and CSS MP browser support. The decision also confirmed that JavaScript support was not a key dependency.

The single page app

SPA apps are ideally suited to handle many of the constraints of mobile browsers. Nevertheless, we didn't feel comfortable completely eliminating support for browsers that did not meet the requirements for delivering an SPA experience. Luckily, the original Mileage Stats app had been designed using principles of progressive enhancement. If the necessary features were not present, the app would simply serve the base experience with no enhancements, relying on full-page refreshes to submit and manage content.

This made our decision to support devices with limited JavaScript much easier, as the app logic was already in place for both the Ajax and full-page refresh interactions.

For more information see Delivering the SPA Enhancements.

Experience categories and enhancements

Based on these decisions, we devised two major experience categories:

  • Wow – An advanced, SPA experience aimed at browsers that support JavaScript, XHR, DOM manipulation, JavaScript Object Notation (JSON), and hash change events.
  • Works – A baseline experience that would rely on simple page refreshes, and is aimed at browsers that did not meet the more advanced Wow criteria.

The experience would not, however, be limited to the criteria outlined for these two groups. We planned to implement additional micro-layers of experience based on the capabilities of the browser or device. These would include:

  • Using CSS3 media queries and basic responsive design principles to adapt the layout for different screen sizes.
  • Enhancing the UI using CSS effects such as drop shadows, gradients, and rounded corners.
  • Using a device-pixel-ratio media query to detect high pixel density devices, and provide them with high-resolution graphics.
  • Using geolocation data (where supported) to offer a list of nearby gas stations based on the user's current location.
  • Generating custom pre-sized bitmap charts on the server and exploring the use of canvas to deliver dynamic charts where supported.

The experience each device would receive would therefore be an aggregate of features based on that browser's capabilities. Rather than implicitly detect a device (or platform), and place it within a particular group, we would detect key capabilities (such as JSON, XHR, or location support) and use these to determine the most appropriate collection of functionality to provide.

The Whoops device group

A third experience level, entitled Whoops, was also created for extremely old or basic browsers. While these browsers met the base requirement of HTML 4.01 and CSS 2.n support, the browser implementation might not be robust enough, or the devices might be too small and/or underpowered to properly run even a basic Works experience. In most cases it was simply due to small screen size (typically less than 320 pixels wide), which resulted in an excessively cramped layout. While it might have been possible to detect these devices and serve an extremely basic version of the layout, the team decided that it was not worth the additional effort as we were already supporting a very wide range of current and legacy (three to four-year old) devices.


The reference app for this project is based upon the reference app for Project Silk. We wanted to explore popular patterns for building mobile web apps, making use of modern features while enabling the app to work on as many devices as was reasonable.

Last built: June 5, 2012