Recent Blog Posts

A user attempts to use a product, and fails.

A developer points out how to use the product, and walks away believing there is nothing wrong with the product.

The developer is wrong. If the user can not use the product, the product is broken.

This key concept to usability is not well understood amongst many developer communities, including (perhaps especially) Java ME and mobile web communities. You can see this in some of the comments I get ... I now know the special tricks for using Gmail and Opera Mini. This does not mean that people can use the products.

The problem is worse - much worse - in the mobile community than it is for desktop applications and sites. Problems are introduced the application itself, the environment in which it runs (browser or KVM), perhaps the environment in which THAT runs (Opera and Gmail run in the Java KVM, with problems introduced by the on-device text input mechanisms), the operating system, user expectations set by the device and the operating system, and the actual hardware. And the interactions between each of these.

This is an artifact of organizational silos.

The device manufacturer gets repeat customers, but no incremental income, if the device does not encourage increased use. Take the case in point: the RAZR. I believe the RAZR's user experience is stifling adoption of mobile data services where it is popular, particularly when laptops and Wi-Fi are readily available. Thus most manufacturers focus on pretty looks. Invisible things like the KVM implementation are typically outsourced and ignored, making the Java experience inconsistent with the rest of the device and creating another source of dissonance.

Carriers are taking over the main screen of the device, but their own organizational silos are getting in the way. The folks responsible for downloads know nothing about the KVM or the browser or the device. Subsidy decisions are made based on increasing one division's profits, at the expense of the folks working on data services.

The web site and application providers sit back and say "just get a better phone" or "it will be better when MIDP 3 comes around" or "We'll support Nokia/RAZR". They make the assumption that the user will be able to get to their site/application, even though that may be difficult for the user to figure out.

The user, paying for all this, gets left out in the cold.

And the product is broken, even though it passed all its tests. The user can't use it.

If carriers/operators don't step in to fix this, somebody else will - making the carrier become the bit-pipe they have feared to be all these years.

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 second set of patterns will address screen design for mobile applications.

Tabs are a common mechanism used to arrange more controls than can fit on a single page. Common desktop examples include Windows preferences dialog boxes and Apple.com or Amazon.com web sites.

Design

No changes from desktop tab navigation: what works on the desktop works on mobile, if on appropriate devices.

Restrict the number of tabs to that which will fit in one row on the screen.

Applicable Devices and Platforms

Stylus devices.
Tabs are also acceptable when all of the following apply:

• a scroll and select device
• with 4 way navigation (including left and right)
• a platform with access to left and right controls
• a platform that allows vertical scrolling to go line-to-line and not just control-to-control
• a platform with focus control
• initial focus is placed below the tabs

None of the major browsers support all of the above. MIDP 1 doesn't support it. MIDP 2 can, but will have to be designed very carefully and tested on all devices.

When Used

Same as desktop tab navigation.

Rationale

Same as desktop tab navigation.

The limitations on scroll-and-select devices arises from the small width and the need to scroll past each of the tabs individually. The experience can be replicated on many desktop sites: try using a site with only tab, shift-tab, letters, numbers, and enter/return. No mousing allowed. Tabs become quite tedious, as do left side navigation.

Sometimes it is worthwhile to display the number of bytes either in use or transferred. Unfortunately, most byte (or bit) counts are counterproductive.

visual grouping

You learned it in elementary school, keep doing it:

4,213,724 bytes not
4213724 bytes

Most people can't count the number of digits when 6-10 of them are in a row, unless they are extremely careful about it. They won't bother.

relevant accuracy

If we're measuring 7 digits, it is unlikely that the user cares about anything beyond the first 3.

4,210,000 bytes not
4,213,724 bytes

dynamic labeling

Related to the above, keep the labels relevant to the amount of data in question.

4.21 MB not
4,210 KB

consistent terms

While most people can't tell you the difference between bytes and bits, they do have a basis for comparison. When talking about transfer speeds, use bits. When talking about storage, use bytes.

4.21 MB not
33.68 Mb

If it's worth showing, it's worth showing so that users can read it. If it doesn't matter that users can't read it, then don't show it.

Like many other large-screen experiences translated to the small screen, video in general and sports in particular does not shrink well. Using the same camera feeds that are intended to work on large-screen televisions will dissociate viewers from the content. The ball will be lost, and even some players will be lost.

All is not doom and gloom, as some techniques exist to enhance the user experience to the point of being enjoyable. At a minimum, the recommendations in Producing MultiMedia Content for Mobile Distribution still apply: basically, choose your content with an eye towards mobile distribution. To do it right for a sporting event, you'll likely want additional cameras whose operators are trying to get mobile content, plus an additional producer to put together the right stream for mobile.

But can you truly watch a soccer (sorry, I'm American) game on a mobile? For me at least, over half of the enjoyment is from watching the dynamic patterns made by the players as the play unfolds. This is exactly the type of footage that is abysmal on the mobile: 240 pixels wide to capture 7 players, a ball, and a third of the field results in a one-pixel ball (if you're lucky).

So what is an intrepid mobile sportscaster to do? Our (Little Springs Design) recommendation is to take a lesson from American football production, with its visual effects that enhance the understanding of the game*. We recommend dynamically detecting the location of the players, officials, and ball on the field, then creating a picture-in-picture display that provides the location of each player at all times. The main part of the screen would display close-up action of players battling for the ball, a shot on goal, or other meaningful content.

This basic idea can be expanded, perhaps even interactively. Is there a particular player on the field who is sure to dominate? Make his abstract representation (likely a colored dot) brighter or even bigger than the other players. Maybe the viewer wants to pay attention to a couple of his favorite players, or is perhaps studying a particular position? Let the viewer select which player-dots to emphasize.

If you're thinking that this sort of representation could enhance viewing even on large screens, I agree. So the additional investment to produce mobile content may enhance all viewer's content.

If you're thinking that you could charge an additional fee for providing this information, I agree - with the caveat that the first few games should be free!

There are several possibilities for enhancing mobile sports content, and I expect the innovation to accelerate as the market shows more promise.

*If you haven't seen it, American football broadcasters display the location of the all-important first down line by "painting" it on the field exactly where the line is, and some broadcasts also "paint" an arrow for possession and number of yards to the first down on the field. I've seen something similar with some rugby broadcasts.

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 second set of patterns will address screen design for mobile applications.

A menu is a list of commands. It can be the main screen of an application, or a set of commands applicable to an item or part of the application.

Design

If the number of actions available for a given screen exceeds ten, divide the list into frequent and infrequent commands, where the number of frequent commands is eight or fewer. Provide numbered access to the frequent commands, and unnumbered, or even submenu, access to the infrequent commands. Figure 6.4 illustrates a mix of frequent and infrequent commands.

If a command is used in multiple places across the application, and is frequently used, keep both the label and the number the same throughout. This policy increases learnability for the entire application. Figure 6.5 illustrates common commands with the same numbers, even though the numbers are not consecutive.

Limit the number of commands listed on a page to roughly fifteen. Keep frequent commands clustered together at the top of the list.

Exception: if the device has an alphabetic keyboard and the platform supports letter input, construct the menu with appropriate alphabetic shortcuts instead. Limit the list to the number of items that can reasonably be displayed and mapped to letters. Any additional items should be relegated to "More", "Other", or the equivalent.

Applicable Devices and Platforms

All scroll-and-select devices with platforms that support button input for navigation.

When Used

Use in menus where the user may want to build expertise, navigating quickly using numbers rather than scrolling.
Applies to any application using a page model rather than a screen model, in which vertical scrolling is assumed. This includes most list-based applications. Numbered access can be used on a non-scrolling application, but the incremental value of the numbers is lower.

Rationale

Keypresses should be kept to a minimum for common actions. Unlike a desktop, a keypress is not simply a mouse click, but the number of times the cursor has to be moved to get to a command, then the command itself. For a Gmail message, for example, getting to "Archive" or "Next Message" can be ten or more keypresses. Numbered access allows that to be one keypress, although it is restricted to users who choose to learn more about the application. On the other hand, numbers do not harm usability by novices and indeed provide visual cues that certain commands are somehow different.
Keeping items clustered based on frequency is a standard heuristic for screen and control panel layout inherited from human factors. It restricts the area users have to scan for the most common items. Structure within the frequent commands can reduce scan time further.

I recently wrote about Opera Mini on a Treo 700p, and I completely missed the fact that the menu bar, which looks exactly like softkeys, was not softkeys. They were buttons.

While the application works, it is still flawed. Flawed to the point that we could not figure it out. Now that we have the trick, it is easier (but largely inaccessible using the thumb because it is at the bottom of the screen). We can use Opera Mini normally, except the cognitive dissonance.

There are several design workarounds, including making the buttons look like buttons or putting the menu bar at the top for the Palm. Either would eliminate the problem and make the browser work more like other Palm apps.