Recent Blog Posts

In a recent presentation, I addressed the future of mobile browsers and mobile web. For browsers, I want Opera Mobile features plus ...

• manage multiple info sources by:
  • user-generated mashups
  • split screen views
  • rapid switching between pages/apps
• available on mass-market phones
• camera, sensor, location input
• local data storage

I also want to see "un-browsers". This addresses things wrong with the mobile web and key issues in the browser model, such as reliance on constant availability of the network, accessibility of data locally, availability of local device capabilities. Specifically, features should include:

• local data & application logic
• synchronize data with server
• standby screen widgets (Apple, Yahoo!)
• device-native AJAX (or similar)
• rich user input: camera, location, haptic, voice
• widgets reusable on desktop

The industry as a whole, or at least certain players within the mobile industry, have been moving in this direction. The boundaries between web sites and applications are slowly degrading. Application-only companies like mFoundry has created a "mobile AJAX" framework. The main mojax page doesn't reflect the full story, so instead check out the rather informative mojax blog. It's in private beta, so I can't assess how well they did technically, but the blog certainly reflects an understanding of the lists above. For example, they describe "Moblets" (applications written in the mojax framework) as the following:

Moblets are applications... not web sites
In fact, because mojax runs as an application and not a website, an mojax Moblet offers distinct advantages over a Mobile AJAX application running within a browser:

1. Local Data Storage (Caching)
All Moblets have access to a global object called Cache. Via this object, Moblets can persist state across application sessions. It can be used to store simple string values, large XML data models, or even images.

2. Offline capabilities
Unlike a browser based application, Moblets can be written to work offline. All the application logic is cached upon install and unless the application requires access to an internet resource (e.g. Web Service) then it is fully capable of running offline and without a network connection of any kind.

3. Access to device specific features
Browsers running on a mobile device are strickly limited to rendering a web page. Granted, in concept AJAX provides a very rich experience, but it doesn't provide access to device specific features like Audio and Video playback, camera, LBS, and Bluetooth. These are all things that a Moblet running on mojax can access.

So I'm hoping to see more from mojax, and hoping to play with it soon.

In a recent project, I was evaluating the design of a set of mobile web pages. The company had outsourced a new ecommerce section of their web site to a new company, and had asked the outsource company to replicate their current user interface. New features and pages were added while maintaining core design.

The outsource company did just that. They created a web site that was visually indistinguishable from the main site. But the user experience was demonstrably much worse than the main site.

The problem? The developers were following best practices for the regular web, but largely ignored the various best practices for coding found in, among other places, in my UI Design Guidelines for Mobile Web Development.

I didn't get the chance to view their code (this is sometimes tough to come by for a user experience consultant), but the evidence is that they performed one or more of the following non-UI sins:

• tables as web layout, causing extra processor load
• percentage sizes for layout (table or CSS), causing extra processor load
• separate CSS, causing an extra http request and content that moves as different parts load
• images contained in CSS, causing yet another http request along with content movement
• large pages with possibly hidden elements, causing memory overflows
• complex CSS, with dozens or even hundreds of selectors, many unused, causing memory overflows and extra processor load

Although each of these does not touch the user interface, they have a profound effect on the user experience.

In the case in question, item transversal time grew by more than 800%. That is, pushing the down button caused the item highlight to move down, but up to 2 seconds later. Of course most folks just push down until the proper item is highlighted, which won't work for this system.

Further, page size was so large that back and home functions frequently failed, claiming that the page could not be displayed. So the only way to start over was to .... exit the browser. Obviously the browser design made this worse, but the largest problem remained in the web code.

This post is part of a series on mobile user interface design patterns, excerpted from Designing the Mobile User Experience, John Wiley & Sons, 2007. This third set of patterns will address application navigation design for mobile applications.

While games vary greatly, the navigation structure to support the game should not.

Design

The basic navigation for games is fairly standard, but screen design varies with device and game. Figure 6.7 illustrates key elements of the most commonly used game architecture.

Upon launch, a splash screen identifies the application and developer. Typically next the game displays a main menu, with a first item, already highlighted, to play. Other actions such as Options (always including volume on/off and vibrate on/off), High Scores, Instructions, and Exit are in the main menu. If a game has been saved, the application displays the in-game Paused menu.

Within the play of the game itself, there must be a quick Pause function. This is frequently the right softkey but can be any number of things. When the game is paused, the "paused menu" is displayed, which allows the user some context-specific functions including exit. The first item in this menu is Continue, allowing immediate one-click return to the game.

Figure 6.7. Architecture for the non-play portions of a game. Representations of Options, High Scores, and Instructions have been removed from the diagram but should remain in the actual applications.

When the device interrupts the user with an incoming call or message, the game should automatically pause itself.

Other screens within the game should follow best practice design.

Applicable Devices and Platforms

Downloaded applications and some scripted browser web pages.

When Used

Even games that need not have a pause function due to a lack of time pressure can use this structure. Be sure to not count pause time in any game timers.

Rationale

This design is strong due to extensive standardization across games, the need for the device to do something when paused, the need for certain navigation functions during game play, and the standard approach of starting with the main menu of an application.

Users tend to have one of two behaviors when interacting with a list of news stories or email: after they read an item, they either read the next in sequence or they return to the main list to select another story. As users become more adept at managing a particular information source, their strategy will shift between one of these and the other. For example, when reading my inbox I typically pick things that will be fast to deal with first, clearing them out. On the other hand, when reading my mailing lists or news folders, I simply read them in sequence. Some RSS feeds I simply read in sequence; with others I skim the headlines.

The design of most email desktop software supports both methods, with the list of email up top and the actual message below. The desktop-focused web mail clients support both to an extent, with "Previous message" or "Next older message" or some such controls on the message itself.

On the mobile it really isn't possible to simultaneously display the list and the message due to small size, so the list and items need to be separated. This doesn't change the user's desired behavior.

The list navigation pattern supports both behaviors. The mobile Gmail applications, both web and local, don't (at least not the four versions I tried). I miss them.

Several devices have Back mapped to a softkey. I think this is a bad idea, especially in a device with heavy web emphasis: the Back button is the browser control most used, by a long shot. It deserves its own button.

Some browser designs (Cingular's RAZR, for example) have a softkey devoted to Back until the user has returned to the home page - at which point the softkey converts to Exit. This well-intentioned design causes users to think that's the only way to exit the browser. It also causes users who repeatedly hit Back to get to the home page to inadvertently exit the browser.

Another function, End, has its own button. Most devices use this button to return to the home screen, exiting whatever process was being performed. In my experience, Java devices have exit mapped to the end key, although it displays an awkward confirmation dialog. Regardless, it works.

Some devices do not have a huge need to exit applications. These devices (higher end phones like Blackberry and Nokia Series 60 devices) have enough memory that a widgets or email application can continue running.

Add all this together: Exit should not be on a softkey. Train the users to understand that End gets them to the standby screen. Put Exit in application menus. But don't put it on a softkey. Surely you have actual application functions for the softkey?

In the past, I've recommended that softkey labels be in ALL CAPITALS. This recommendation holds true, but only for older phones.

Older phones had little visual distinction between the content of the screen and the softkey labels. This caused the softkey labels to look like the the content of the screen. Making the labels be all capitals created that visual distinction.

Device manufacturers, with more processor speed and better displays, now have an effective visual distinction between content and controls. It is obvious that the softkey labels are obviously, intuitively, not part of the content. As a result, softkey labels should be in the most readable format - usually Mixed Case.

The corollary to this issue is that things that are visually distinguished at the bottom of the screen should actually be softkeys. Users are learning that a bar at the bottom of the screen means that the items are soft buttons, operable by the hardware buttons immediately below. Make them work that way.

Other softkey labeling mechanisms continue to hold constant: keep the labels short, avoid multiple-word softkeys, and keep the action clear.