This article is for those managing the development of handheld applications. What follows are some guidelines that you can use when deciding how your new handheld application will look and operate.

When you’re developing an application, a lot of forces influence the decisions you make. The owner of your company (who came to power during the early MS-DOS era) may have strong feelings about what should go where and how it should look. The software programmers will have their own staunch opinions. And finally, the fun-loving “end users”—the people for whom the application is being built—will have very distinctive thoughts about the way things should look and work.

Part of your job is to provide suggestions and standards that everyone will agree upon. You already know the fields that are required, the data rules, and all of the hooks to other applications. Now you are getting ready to lay out the actual screens. Where, oh where, do you start?

In the beginning IBM created CUA

Long ago, IBM defined “common user access” (CUA) guidelines to provide a standard for developers to follow when designing screens. Many of the good points of CUA can assist us today. For example, one of the CUA guidelines suggests that programmers include a pop-up dialog box confirming the user’s intentions whenever the user tries to delete a record. Most of us are quite happy to have had the chance to change our minds about a delete as a result of this guideline.

Below are my user interface (UI) 10 commandments to consider when creating your own application for the Pocket PC.

1 Thou must chooseth between scrolling and paging navigation.

Whether you are buying or building your application, one of the biggest user interface questions that you will need to answer is which page navigation model you want to use.

With the scrolling navigation method, data fields are displayed in a long Web page-like form and you use a scroll bar to navigate up and down through the form. It maps well to Web, Word, or Adobe Acrobat content, but can be annoying to users who are forced to move the visible screen up and down to work with the application. More of a problem is the fact that users tend to forget what they can’t see. Entry fields that are buried down off the screen will likely be skipped by the user—at least until your page-turning logic pops up an error message and sends the (now really annoyed) user back to the fields that were skipped.

The alternative is to use paging navigation, where you divide the information or data fields up into separate screen-sized pages. If there are only a few pages (screens) per record, you can have the user access the different pages using tab controls. If there are more than a few pages, you can place [Prev][Next] buttons at the bottom of the form, which direct the user to the desired page. Using this model, a screen’s worth of information is never longer than the display area provided by the device. These navigation controls only take up a little bit of screen real estate. In addition, they are useful in that they can be disabled until all required information has been entered on a given page. This provides a sure visual sign to the (now less annoyed) user that they have correctly filled out a screen before they try to continue.

Note that one drawback to the Prev | Next approach is that screen size will vary across devices, which generates some extra work for the developer.

Chose the navigation style—scrollbar or Prev I Next.

2 Thou shalt only use one font and only 1 or 2 different font sizes.

Ah, this is the first place that developers head for when playing with a new environment. You will see italic fonts; three or more sizes of fonts; bold fonts; normal fonts; humorous wing-dingy fonts—generally more fonts than you can shake a stylus at.