Recent Blog Posts

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.

It's generally useful to have an agreed-upon definition for what an industry does. So, what is the wireless industry? What is a mobile? Does it have to be a phone? What about a Blackberry or Sidekick?

Lets start with the devices. A Blackberry is definitely in. An iPod is definitely out. It doesn't have connectivity and isn't used for communications. What is the difference?

The wireless industry is focused on communications. I propose we refer to the set of related devices as Personal Communications Devices, or PCDs. These are epitomized by mobile phones and text communications devices like the Blackberry.

• Personal. The device generally belongs to only one person, and is personally identifiable via messaging address and ongoing service.
• Communicative. The device sends and receives messages and connects with the network in a variety of ways.
• Handheld. The device can operated with a single hand, even if two hands or a hand and a surface are more convenient.
• Wakable. The device can be awakened at a single touch by either the user or the network. A mobile phone will receive a text message even when in its "sleep," or standby state. Note that most computers, if they are asleep, can not communicate with the network.

This combination of features conspires to make the service indispensable and the PCD an ever present part of the user's life. The service represents safety and social connection. Because the service is indispensable, users tend to carry the device with them all the time. This fact forms the core of understanding mobile user experience.

The fundamental distinction between mobile-targeted design and design targeted for other platforms is The Carry Principle: the user typically carries the device, all the time.

Mobile applications, and especially mobile games, are frequently used in short bursts. These bursts could be due to short attention span, short task, incoming call or message, the train arriving, or any number of other things. Thus the user will frequently exit the application, either intentionally or unintentionally.

Once the user exits the application, if you don't want her to use the application again, do some of the following:

• Have an unnecessarily large application footprint. That way, the application will take a long time to load, so the cost of restarting the app is high.
• Phone home with every launch. This technique lengthens the time until the user can start using the application again, prohibits her from using it without coverage, and can run up her data charges. You wouldn't want to set a time stamp for end of license and only phone home when the license has expired - no, that would let people back into the application too quickly!
• Don't save user data. If the user has to re-enter data, she is less likely to use the application again. If she gets interrupted in the middle of searching for an airplane ticket, by all means erase all the search parameters.
• If you have to save user data, save it for a long time. Our fearless user will definitely want to search for a ticket for August 12 the next time she uses the application - on August 15.
• Be oblivious about user context. You know that your user is on that trip to Tokyo ... offer her information about events happening in New York! Especially if she lives in London.
• Destroy user state. A more advanced version of "don't save user data", this will require users to start at the home page or main screen every time she starts the application. You wouldn't want to return her to the news item or video clip she was viewing two hours ago - make her find it again!
• Force a single user interface onto all devices. Especially fun is requiring touch screen users to use virtual hardware buttons, but using one of the softkeys as "Back" on a device that has its own Back button is particularly popular. Couple this with making the hardware back button inert! After all, the user knows how to use her own device's user interface paradigm: you wouldn't want to support that.
• Use a tiny font and subtle colors. This technique increases users' eye strain.
• Don't remember the user. Requiring the user to type a user name and password each time adds to the experience. Advanced: require mixed case, numbers, and symbols in your passwords.
• Expire passwords and sessions after a couple minutes. Those of you in the financial sector know all about this one, but some of the rest of you haven't tried this trick yet. Because somebody might walk away from a computer and expose secure data to prying eyes, keep the session timeout for a mobile device very short, because people walk away from their phones all the time, letting strangers use their connection and services.

There are more methods. Can you give me your favorite? I'll post a new collection in a few days.

Note that when you comment, an error will appear. Your comment has indeed been received and will be unscreened soon. We are working on this.