User Interface

Another important part of making your application easy to use is making it easy for people to discover its features and figure out how to utilize them. To make your application feel intuitive, keep the user interface consistent with built-in applications. Adhere to the Palm OS user interface guidelines. A consistent user interface is a familiar user interface.

An application that feels familiar feels easy to use even on first experience. When users first look at your application, they will explore it, and they will try to figure it out. Every little thing that they have to think through is like a little speed bump. Each time a user encounters something unusual in your application's user interface, something that works differently from other applications, the user must take a couple of extra seconds to figure it out. (Or the user might not figure it out at all.) These disturbances have a negative cumulative effect.

Stick to the user interface guidelines

Your application gets a positive cumulative effect if it sticks to the user interface guidelines. It leverages everything the user has learned about the standard user interface from other applications.

For example, the user recognizes a command button and immediately knows how it works. The user taps the button, and it behaves exactly as expected. This button adds nothing to your application's learning curve.

If you can limit the number of speed bumps, users will get through your application and think, Wow! That was really easy to figure out. They just picked it up, started playing around and got it to work.

Example: Train Catcher

Let's take a look at an example application that illustrates some of the design principles and practices we've discussed. This is the imaginary Train Catcher application, which you might find useful if you were traveling by subway in Japan. When you are transferring trains and there are six different trains leaving from four tracks, Train Catcher helps you figure out which train to take. Figure 1.5 shows a first design for this application.

Figure 1.5 Example application design, first pass

At the top of the screen, three pop-up lists let you specify which train line you want, your starting point, and your destination. Below that you specify the time of the earliest train you want to take; this would be the current time by default. The bottom half of the screen presents some options: you can select the weekday schedule or the weekend schedule, and you can set how the list of trains will be sorted. To use this application, you would configure all these settings, tap a button, and the application would generate a list of all the trains you could take.

This first pass at the design is very busy. There's a lot of stuff on the screen, and your eye wanders all over the place. You notice the icons at the bottom of the screen, but you don't really know what they do. In fact, some time after the designer of this example application put those icons there, even he wasn't sure what they were intended to represent.

It's not so unusual for the designers of an application to forget why they included some features or how a feature is supposed to work. When that happens to you, it should raise a huge red flag. If you're knee-deep in the design and you can't remember how it works, then you certainly can't expect an average user to have an intuitive feel for it or figure it out.

This design needs a second pass to clean it up a little. Let's do a layout that's more like the standard Palm OS layouts, as shown in Figure 1.6.

Let's line up the three pop-ups at the top of the screen. Let's add a couple more words to clarify the purpose of the time field. We can eliminate the weekday-weekend indicator. Generally, the user will be searching for trains that are running today. Your application can easily find out what day it is, and show the appropriate weekday or weekend information.

For customization purposes, we might put the weekday-weekend setting on a preferences screen. The sorting option can definitely move to the preferences screen because it probably will not change very often. Since we couldn't remember what the icons do, let's get rid of them. One of the icons probably started the search for trains, which is the application's most important function, so let's make a text button for that function.

We now have room to add a button for another useful function that shows when the last train leaves. In a city where some trains don't run 24 hours a day, this button tells you how late you can stay without missing the last train and having to take a taxi home. This new button does not clutter the layout, because we removed nonessential objects. This last-train function is exactly the type of feature you will add if you are focused on solving the user's problems, as opposed to padding the design with incidental features such as a weekday-weekend indicator. Users will say, "Great! That's just what I wanted to do."

This second pass could still be improved. For example, the field label "Display trains after" could be rewritten less ambiguously. It might say: "Show trains that leave after:" Your label would be a little longer, but also clearer. And you provided the extra space required by simplifying the original user interface.

Application design is an iterative process, like editing written material. In the first pass you just throw everything on the page. Then you hone it down. You show the second pass to people and get feedback, and you realize it's still not good enough. Then you get user feedback on several more passes. Iterative design is what really makes a great application, rather than just giving it a shot and calling it a day.

Taking the editing analogy one step further, designing a handheld application is more like editing a poem than editing a novel. In a novel, you're not very concerned with size. In a poem, every single word and every punctuation mark has its place. A 17-syllable Haiku poem is more exacting to write than a 600-page novel.