User interface styles

Tags: Design,  Design Tips,  Java ME,  Mobile applications
July 29, 2006 by Barbara

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.


«« Verizon billing system doesn’t – and then blames the customer  |  On uploading content »»

No Comments

No comments yet.

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.