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.