satisfies this with a virtual button; Android and BlackBerry devices rely on a physical hardware back button; webOS uses a back button and a back gesture. Whatever the method, users expect that they will be able to “go back” in your application.

Users also expect context menus. In the default Android and BlackBerry browser, the context menu is accessed through a physical button found at the bottom of the screen, close to the natural position of the thumbs. On iOS and webOS the context menu is accessed through a persistent virtual tab bar positioned close to the thumb at the bottom of the screen. The persistent tab bar at the bottom of the screen on devices other than iOS and webOs often produces a poor experience because users can easily accidentally hit their context menu or back buttons, causing an app to close unexpectedly. These are limitations with which both native and Web apps must contend.

Developers must consider approaches that make good sense for both data and users. HTML5 does support the concept of a menu element so a common abstraction is possible here, but the work has yet to be done.

Environment is the greatest wild card of all! Is it daytime or nighttime?

Is the user standing or sitting? Standing still or in motion? One or two hands free? In a busy place? The variables are endless.

Where does that leave us? Expectations borne out of the context are not inherently cross platform. Both native and Web implementations must provide designs and code that support these expectations. The good news for Web developers is that they can fall back on a familiar paradigm in the Web technology stack to satisfy user expectations.

Implementation. To produce the best possible user experience, implementations must deliver designs and code that support expectations set out by a user’s particular context.

 

Performance: the hobgoblin of software Development Without a doubt, performance is a cornerstone of a great user experience. Like security, it is the most misunderstood and oft-used scapegoat of the software developer. It’s not uncommon to hear developers reject ideas with a flippant, “We can’t do that, it will negatively impact performance.” Rarely quantified and frequently cited, performance is the hobgoblin of software development. How do we quan-

figure 2. Variety of contexts across android devices.

figure 3. the variety of mobile Web browsers.

tify performance? Latency is a form of performance. Execution, the time an operation takes to perform, is another. We’ll address these separately.

Latency is a huge consideration in the mobile world. Be it a native or a Web application, there is a performance penalty to downloading an app and the data it consumes or publishes through the network. Obviously, the smaller the payload, the faster the app.

Using JavaScript Object Notation (JSON)-formatted data is a good idea as it tends to result in a smaller data payload compared with an equivalent XML payload, depending on how the XML is formatted. On the other hand, XML data can make sense when returning HTML fragments that are to be inserted into a Web page rather than returning JSON-formatted data that, while smaller over the wire, needs to be converted to an HTML fragment using JavaScript. Your mileage will vary. Benchmarking is the only way to know for sure.

Another latency issue can be the ini-tialization of code. Once we actually get the code into memory, it still needs to be parsed. There can be a noticeable performance penalty in this process. We can fake it and enhance the perception of performance with determinate or indeterminate progress indicators.

Execution time is, of course, a key facet of performance. When interpreting code (as we do for the Web with JavaScript), the more there is to interpret, the longer the execution time. Here the Web technology stack has some catching up to do. JavaScript, for all its leaps in performance, is still slower than native counterparts. On the other hand, the time it takes a programmer to write comparable logic in a native compiled language on multiple mobile devices may be worth the time penalty for execution; however, this will certainly require more maintenance than one code base written in JavaScript that can run on multiple devices, maybe some tweaks per platform. Less code often leads to less and easier maintenance.

That said, the benefit of less code doesn’t matter to the end user, who expects a responsive interface. The developer tradeoff is a larger code base— often vastly larger, considering support for multiple native platforms. In the world of native code, the main challenge is reimplementing to multiple