This appendix summarizes ten design guidelines for Palm OS® applications that developers often forget or ignore. It then tells you which sections in the book explain these guidelines in more detail.
- Consider the user.
The most common mistake handheld application designers make is the most common mistake made by all application designers everywhere: they fail to learn about the user before designing the application and thus fail to provide an application that solves the user's problems.
"The Design Process" describes a process that helps you to create an application with the user in mind at all times.
- Don't overcrowd the screen.
A user must be able to learn your application quickly and navigate through the display quickly. If you clutter the screen with too many controls, you slow the user down. See "Fast and Simple" for more information.
- Don't provide an Exit command button or an Exit menu item.
Palm Powered handheld users do not exit applications. They simply move to another application. See "Don't Provide Save or Exit Commands."
For a description of when breaking this guideline is allowed, see "Including an Exit Command."
- Let the user leave your application.
You must allow the user to exit the application at any time. If you're displaying a modal form or an alert dialog, you must provide a default button. When the user exits your form, the system simulates the default button tap. See the following sections:
- "Exiting the Application"
- "The User Can Exit at Any Time"
- "The User Still Can Exit at Any Time"
"Modal Forms that Don't Exit" describes the one allowed exception to the rule.
- Launch quickly.
Applications should not display a splash screen when launching unless this is the first use of the application. Most applications should return to the last form that was being displayed before the user exited the application rather than always displaying a main screen at launch. See "Launching the Application."
- Use modal forms sparingly.
In general, modal forms should be used for a single specific task only. Modeless forms are greatly preferred over modal forms. See "Choosing between Types of Forms" for further discussion of when to use modeless and modal forms.
- Don't duplicate commands.
There's usually not a good reason to provide both a command button and a menu item for the same command. See "Don't Duplicate Commands" and "Duplicating Menu Items".
- Remember the Graffiti® Shift Indicator and Edit menu.
All forms with editable text fields must include a Graffiti Shift Indicator and an Edit menu. Even modal forms require the Edit menu to be present. See the following for further discussions:
- "Edit Menu Required"
- "Graffiti Shift Indicator Required"
- "Enable Auto-Shifting for Most Text Fields"
- Set the field focus.
In almost all cases if you have an editable field on a form, the field should have the focus when the form is first displayed. This must be set programmatically. See "Set the Focus When the Form Is Displayed."
- Leave room for the border of an object.
For all user interface elements, the border is drawn outside of the bounds of the object. The guidelines state that all objects should begin at the left edge of the screen. If, for example, you place a command button on the screen, it should actually start at pixel 1 to allow for the 1-pixel button border.
See "Left-Align Buttons at the Bottom of the Form" for further discussion.