I am no longer updating this site; all content is available at my main site, Little Springs Design.

Fitt's Law applied to mobile devices has different implications for mobile UI design than it does for desktop design. Let's focus in on the dominant user interface type, the scroll-and-select device. Let's further assume a one-handed device - no QWERTY keyboards.

Hardware Design: What is close and what is far?

The device rests in the user's hand. The thumb can readily reach the number buttons on the phone, although some clamshell designs have a heavy top half, shifting the neutral resting point of the thumb. If we assume the user is using some type of application, one or both thumbs are in ready reach of the navigation buttons.

There are, on most phones, two key regions of buttons: numbers, and navigation (some or many of: softkeys, left/right/up/down, select, back, camera, etc.). Applications with intense number button use will find users with both thumbs hovering over the number buttons. Applications with intense navigation button use will find users with thumbs hovering over navigation buttons.

A mixed mode - number and navigation button use - is fine as long as neither is intense. Use slowed if the user has to do significant movement between regions due to shifting intensities.

Software Design: Optimizing for Speed

On a scroll-and-select device, distance is measured by the number of clicks to accomplish the task. Clicks include scrolling through the screen, pushing a Select button, pushing a softkey, scrolling through a softkey menu, and activating an item in a softkey menu.

Distances are increased when the hardware buttons are far from the user's current thumb position.

As an example, consider a Nokia phone, without a select button, on a standard Options/Back screen. Item X in the menu is highlighted. What actions are closest?

At 1 click, we can go Back (or Cancel, or whatever the right softkey is doing right now) --- or activate any control with a number shortcut.
At 2 clicks, we can select the currently highlighted item (Options -> choose).
At 3 clicks, we can select a neighboring screen menu item or a neighboring Options menu item.
And so forth.

On a phone with completely customizable softkeys, a Back button, and a Select button, what actions are closest? Let's assume that there are several commands available, and all but the most frequent are relegated to a Menu on the right softkey.

At 1 click, we can go Back, select the currently highlighted item, or the most frequently used command (on the left softkey) --- or activate any control with a number shortcut.
At 2 clicks, we can select a neighboring screen menu item or perform the second most frequent command.
And so forth.

So on a phone with unassigned softkeys, everything in the user interface is "closer" than it is for that Nokia device. (at the cost of more hardware buttons). The softkeys serve the same function as right-click on a Windows computer.

We now have a decent measure of what is "close", which can be performed on any device with any platform. Be sure to include platform considerations: while traversing 45 links on some browsers is 45 clicks, on the Opera Mini, with its left/right arrow page scrolling, it may be only 6 clicks.

So if you are designing for speed of interaction, this analysis suggests the following:

• When designing for Nokia devices, order the commands in the menu by decreasing frequency


• Provide numbered access for visible frequent items on the screen (as well as anything the user may have learned)


• Use the Select (OK) button, if available, to select and activate screen controls.


• On non-Nokia UI devices, assign the most frequently used command to the primary (usually left) softkey


• On non-Nokia UI devices, assign the other command, or a Menu label, to the secondary softkey.
  
• If a third softkey exists, assign a command to it.


• If creating a menu of commands, order them in decreasing frequency order.


• Allow lists, particularly command menus, to wrap so the user can push up from the top item to get to the bottom item.

Note: I have simplified phones into Nokia UI and non-Nokia UI for discussion purposes. More complexities exist.

Of course Fitt's Law is not the only consideration in user interface design - but it is an important one.

I just looked at Brian Fling's Designing for Mobile presentation, which is intended to help folks get started in the mobile space. It's a good read, it organizes many things nicely.

This spoke to me quite a bit, as I am now wrapping up work on my book, Designing the Mobile User Experience, to be published in January. This book is intended to help marketing and product development professionals, particularly user experience folks, enter the mobile space.

With that in mind, I believe there to be some inaccuracies within Brian's presentation. Some are minor and not relevant, such as the assertion that 2G devices were voice + SMS only and ignoring 1xRTT as part of 2.5G. Relevant inaccuracies include:

• Cingular's terms of service, as of March of this year, specifically prohibit visiting sites outside their content. I fail to understand how this is not a "walled garden"


• Sprint's search engine searches all mobile-optimized sites, and allows direct URL entry for any site. I fail to understand how this is a walled garden.


• Similarly, Verizon has blocked URL opening from SMS messages. Walled? Seems so.


• I have seen no semantic difference between carrier and operator. As best I can see, "operator" is a more European term, and "carrier" is a more American term.


• Brian advocates writing for "feature phones" not "smart phones". A good place to start, but we should remember that smart phone users use more data services, so they are potentially higher users of a given application.


• As more and more people use the mobile Internet and other mobile applications, a larger percentage will be using the mobile as their primary use. Thus functionality that is available on the desktop should, if possible, be available on the mobile -- but not at the cost of the primary user experience! Infrequently used information should be in harder-to-access places.


• While XHTML-MP may be "often referred to as WAP 2.0", that is flat out wrong. WAP is equivalent to HTTP, not XHTML. The WAP 2.0 collection of standards includes push messaging, XHTML, XHTML with WML extensions, location services, transfer protocols and more.


• Flash is available on Verizon, KDDI, and NTT DoCoMo devices, which is a bit beyond "available to developers only". And SVG should be mentioned somewhere.


• J2ME (which ought to be called Java ME) content can run on BREW devices via a BREW-authored KVM. Thus J2ME can go to Verizon devices.

Regardless, it's a good start, particularly for a relatively short presentation. If you're new to mobile design, go read it. And order my book.

Too many designers and developers treat all devices with scroll-and-select input and softkeys as the same, and design one application to work on all such devices. Unfortunately, that can result in users being unable to use the application, and abandoning it.

A user interface style is a device operating system's input method, softkey use policy, information organization, select key use, and visual design. A device's user interface style strongly influences its users expectations and perceived usability.

Both Nokia and Samsung phones tend to have two softkeys, but they are used quite differently. The Nokia device will in most situations display "Options" on the left softkey; the Samsung device may have the left softkey serve as the select function, or may have it be selection dependent. While both these devices use the softkey to, in some fashion, perform the select function, other devices (including some Nokia devices and most Sprint devices) use a separate selection button, so users expect the softkey to perform something else.

The folks who designed MIDP's "abstract commands" knew this, and relied upon the device's environment to decide what type of actions should be activated by different buttons. Unfortunately, many device manufacturers and KVM environment developers are unaware of the issue, and allocate the commands haphazardly. Regardless, the folks who know the device's intended user interface style intimately have the best chance at getting the design right, so relying on this is one of the better strategies.

Browsers generally violate the device's user interface style, usually through a simplification. This was more of a problem in the past, when the user experience of the browser and the the operating system were the same: all text. Browsers can get away with this because there are really only two things to do on a page: follow a link, or do something that affects the whole page or even the whole browser (back, enter URL, options, exit). Even so, don't put a Nokia browser onto one of those Samsung devices: the back button won't work, the button labeled "Menu" will suddenly go back, and the OK button will display a menu!

I feel that browser use is diminished by this phenomenon. I know that application use is. If I end up making several errors on a well-practiced application because it just doesn't work the way the rest of the device does, I can expect that most users will not be able to use it at all.

What's that argument I hear? Oh, I understand now: "We want consistency between devices!" I definitely understand that desire. So tell me: how many of your users will use your application on multiple devices? 5%? Wow, that's quite high. Most people use one device, not two.

Are your users expert at each device? If so, then the inconsistency in how your application looks will be irrelevant: the device will cue the user how to use the application, and the user will appreciate the streamlined experience on each device.

So how many of your users are using the same application on multiple devices, who are not expert at the use of each device? If you have any, it certainly won't be many. Less than 1% in most cases. So .... why are you sacrificing the experience of 90% of the users for a handful of edge cases? Stop that, will you?

No, don't worry about folks switching from one device to another. Many times they will pick a device with the same user interface style. When they don't, please expect them to learn the new UI style quickly. Sticking to a single style in the application

Oh, I hear another argument: "Our support team has to be able to tell users how to use the application!" This one makes sense too. So you are a development organization, right? You have an information system for your support team to use? Do you have any access to it? (If not, you are in big trouble)

This problem is solvable. If we look at the worst case scenario, voice support of a data application with no user registration necessary, it is still possible.

If you have a little extra space in your main menu, put a "About" item. Have your support staff direct the user to "scroll to 'About', and select it. Please read to me what you find there." On this screen is the application build code as well as what the application knows about the type of device.

The support guru keys in the information, which then brings up a version of the script with key items filled in.

Thank you Mrs. Lee. I'll be able to help you a bit better know. Your problem is that you can not connect to your email server, correct? Thank you. Please open up Options. <device-specific information about opening Options>. Now scroll to Servers, and select that. Great. On this screen we are going to check your POP settings. <device-specific information about viewing POP> ....

The script is built with only buttons and function access missing. Part of the design and testing process for specific devices fills in those key fields, perhaps automatically with a sniffer application to be run on each device.

Yes, it is annoying. But you have to do it only once for your company. If you are clever, you find (or found) a company to perform the field-inserting work for you.

In March, I got Verizon service and a phone. I could not use the phone for its intended purpose, namely downloading applications for testing. I returned the phone two days after the grace period expired.

I waited and waited for a bill. I could not log into their site since I had no phone number or phone or account. Customer service couldn't help me because I was not a customer. "They would send me a bill".

Finally, a few days ago, I received a strident letter informing me that my account was delinquent, and I should take steps to resolve the delinquency immediately. I put this letter into my bill pile, intending to get to it within a week.

Today I received a phone call asking me if I would like to charge the amount to my credit card. The lady was very nice, and willing to give me a bit of personal information to prove that she deserved my credit card information.

But ... for those 17 days of service, not including the phone which I returned, I got charged $281. That's $281 for 3 text messages, 2 local phone calls, and 1 $3 application. At least I think that's what it is for - I certainly don't have a bill to show me what is in there.

I just called a colleague, who had subscribed to a "ring back tone" so that instead of hearing rings, I heard music. This was my first experience with this.

Yuck.

It was disconcerting, but I suspect if the technology were more popular, I'd get used to that.

A bigger problem is that the audio encoder/decoder on my phone is optimized for ... the human voice. This allows it to operate quite efficiently at transmission and have very high quality ... for the human voice. (and not very young humans either - I can't understand my three year old on the phone). Please note that instrumental music is not the human voice, although it may have singing along with it.

The quality of the music was so bad that I have no idea what the song was; I am not certain I can even name the genre.

When my colleague answered, there was no pause between the music and the voice, so I missed the fact that he had answered. The two sounds, music then his voice, were both organic and a bit muddled. With the standard ring, the sound switches from a mechanical noise to an organic noise: even if you do not understand what was said, you have a good idea that it was a human.

Finally, Cingular's ad for their version of ring back tones (Answertones, which is a pretty good name) refers to the "boring old rings". Well, those "boring old rings" give me all sorts of information - it's easy to count them, so I get a measure of time. They help me decide whether the call went to voicemail because the phone was off, because the call was sent there, or because the call was not answered. Instead of getting all that useful information, I held the noise away from my ear and just waited. Yuck.

Corporate users have had it available for a while: presence management for verbal communications.

Now Jaiku is providing it for the rest of us, as long as we have a Nokia Series 60. I can't test it out as neither I nor the majority of my friends have a Nokia phone, but the application provides presence, location, and availability information for users in the phone book.

This is the sort of application that could provide stickiness for a carrier if it were given free to its users. Perhaps we'll see a version written in uiOne or MIDP2. It'll take a while.