Documentation  |   Table of Contents   |  < Previous   |  Next >   |  Index

4    Executing Commands

Palm OS® User Interface Guidelines

Palm OS® 68K SDK

This chapter discusses user interface elements that, when selected, perform an action in your application. In other words, these elements execute commands.

There are two main methods of executing commands on Palm OS®:

The first section tells you how to choose which of the elements listed above is best for your application. The rest of the chapter describes behavior and appearance guidelines for each element.

Choosing between Buttons and Menus ^TOP^

Choosing which application features should have command buttons and which should have menu items is a fine art. Command buttons provide instant access but take up valuable screen space (see Figure 4.1).

Figure 4.1  Command buttons

Menu items do not take up screen space, but they are hidden and require more taps to execute (see Figure 4.2).

Figure 4.2  Menus

In general, you use command buttons for common commands and menus for uncommon commands. This section provides further guidelines to help you choose.

Limit the Total Number of Commands ^TOP^

Remember that a new user must be able to pick up a Palm Powered handheld and successfully navigate the system within five minutes. If you have too many buttons, you may overcrowd the screen and ultimately confuse the user. If you have too few buttons, you may end up with an interface that is not instantly understandable or easy to learn. Likewise, providing too many menu commands confuses the user.

Instead of focusing on how many command buttons and menu items you can squeeze in, focus on providing the minimum number required for your application. Running out of space is usually a sign that simplification is needed. Remember that users use 20% of a desktop application's features 80% of the time. You should concentrate on finding the top 20% of the features required by your users and provide commands that implement only those features.

Remember also that you are limited by the size of the screen. Realistically, you can fit only five or six buttons on a form. You can fit three or four menus on each form, and each menu can have at most 13 commands.

Use Buttons for Important Tasks ^TOP^

Use command buttons for important tasks, tasks that are essential to your application and that are frequently performed. Reserve the use of menu items for the less important, less frequently accessed commands.

Using command buttons for essential tasks serves two purposes: They make the commands visible to all users, and they minimize the number of taps required to execute the commands.

For example, all of the built-in applications have a New command button on the main form so that even new users can see how to create a record. Navigating between the main forms of the application is another important task that is nearly always worthy of a command button.

Many users do not even know that menus are available in Palm OS applications. If you place an essential command like the New command in a menu, those people won't find it.

Note that context plays a role in deciding which commands are important and which are not. A command may be important enough to deserve a command button on one form of your application but not on another or a command may be important in one application but not another. For example, most games use a menu item for the New Game operation because it is more important to devote the entire screen to the playing of the game.

Use Menus for Destructive Commands ^TOP^

Just as essential tasks should have a command button so that new users know where to find them, destructive commands should be relatively hidden so that a user does not execute the command by mistake. Menu items are good for this purpose because menus are a somewhat hidden interface.

An alternative is to maximize the number of taps for a destructive operation. For example, deleting a contact from the Address Book is performed by a command button, but it requires three taps to reach the Delete button.

Just as context plays a role in determining which commands are important, it also plays a role in determining how difficult it should be to execute destructive commands. Some applications may want to elevate the importance of the Delete command by placing its button at the same level as, for example, the New or Edit button. Consider an application that loads digital images from a camera into the handheld. In such an application, you may want the Delete button to have the same accessibility as the Edit button so that the user can quickly and easily free up space on the handheld.

All destructive operations should display a confirmation alert before actually performing the task.

Don't Duplicate Commands ^TOP^

Don't provide both a command button and a menu item for the same operation in the same form.

In desktop applications, it's common for there to be both a New menu item and a New command button on the toolbar, for example. On Palm Powered handhelds, screen space is so limited that such an interface is discouraged. Use command buttons for the important, common commands only. Use menu items for infrequent commands only.

Keep in mind, however, that each form in an application can have a different menu. It's acceptable for one form's menu items to duplicate command buttons that appear on a different form. For example, in Memo Pad the main form has a New button to create a new memo. The Memo Edit form has a menu item that performs the same function. This way, the user does not have to return to the main form to create a second memo.

For further discussion on duplicating commands, see "Duplicating Menu Items".

Remember the Goal: Minimize Taps ^TOP^

Don't use a command button or a menu when some easier method of performing the task is available.

Each of the built-in applications allows you to edit an existing record and to display a record's details. They use different means for performing these tasks depending on what fits that application best. The Date Book and To Do List applications allow you to edit a single record in the main form simply by tapping it. For viewing the record's details they provide a command button, so this action requires one more tap than editing the record does. Address Book reverses this functionality: viewing the record's details requires a single tap on the record. Editing the record requires the user to tap the record and then tap the Edit button. (See Figure 4.3.)

Figure 4.3  Minimizing taps in built-in applications

Even though these applications use different means for editing an existing record and displaying a record's details, each uses the best means for its data. In Date Book and To Do List, you rarely need to see more information about a record than is shown in the main form. Therefore, editing the record is more common than viewing the details. In Address Book, viewing the details is more common than editing because Address Book's main form cannot display all relevant information about a contact (such as the contact's address). Each of these applications minimizes the number of taps for the most frequently performed operation.

Use Buttons for Commands Executed by New Users ^TOP^

Provide command buttons for tasks commonly executed by novice users if they are otherwise hidden.

In Address Book, tapping anywhere in the View form takes you to the Edit form. This is a power user feature; two quick taps on a contact listed in the main form takes you to the Edit form. Newcomers may not discover this feature right away, so Address Book still provides an Edit command button on the View form.

You do not have to provide a command button if the functionality is easily discovered, however. Tapping a contact name in the main form of Address Book has no command button counterpart. Newcomers can easily figure out this interface.

Don't Provide Save or Exit Commands ^TOP^

Most desktop applications have menu commands to save changes and to exit the application. These commands are so ubiquitous on desktop applications, novice Palm OS application designers try to fit them into their handheld applications. This is almost never a good thing to do.

You find no Save command in the built-in applications. Palm users are not used to saving changes before they switch to another application. Changes are always saved as they are made. Undo is available if the user makes a mistake in an editable text field, and destructive operations have a confirmation.

Palm Powered handheld users are also not used to exiting applications. On the Palm Powered handheld, users do not think in terms of exiting one application and then launching another. The paradigm is such that they consider all applications to be running at once and they can move between them at will. (In reality, the system only runs one application at a time, and the applications are written in a way that moving between them looks seamless. This is an implementation detail that the end user does not know about.)

Command Buttons ^TOP^

A command button (see Figure 4.4) is a button that has a rounded rectangular border and that performs a command. Place a single a row of command buttons at the bottom of the form.

Figure 4.4  Command button dimensions

Table 4.1 Command button details 

Dimension

Value

Width

36

or content width + 10

Height

12

or font height + 3 if not using standard font

Top

147 (modeless forms)

or 160 – button height – 1

form height – button height – 5 (modal forms)

First Button Left1

1 (modeless forms)

5 (modal forms)

Button(n) Left1

button(n–1) left + button(n–1) width + 6

Border

1 pixel rounded rectangle

Content

Text or graphic that succinctly describes command

System Supplied Behavior ^TOP^

The user executes the button's command by tapping the button once with the pen or with a finger. When the user does so, Palm OS highlights the button while it is being pressed. Palm OS ensures that the command is not executed if the user drags the pen or finger outside of the bounds of the button before releasing it.

Look and Feel ^TOP^

Follow these guidelines for the behavior and appearance of a command button.

Never Require a Double Tap

Never require a double tap on a command button, even as a power user feature. Reserve double taps for text fields.

Left-Align Buttons at the Bottom of the Form

Command buttons belong at the bottom of the form. Remember that the user is working most often in the Graffiti® area. Because the user will tap these command buttons often, it is best to place them at the bottom so that they are nearest the user's pen.

On a modeless form, buttons and all other user interface controls begin at the left edge of the screen (see Figure 4.5).

Figure 4.5  Command buttons on modeless form

On a modal form, you must leave space between the edges of the form and the buttons to make sure that the button borders don't blend with the form borders (see Figure 4.6).

Figure 4.6  Command buttons on modal form

Borders are drawn outside of an object's boundaries. That means to align the button with the left edge of the form, the button must begin at pixel 1. Its border is then drawn at pixel 0. Similarly, to place 4 pixels between buttons, you must actually add 6 to the width and left origin of the button on the left. Adding 6 allows for the left button's 1-pixel border on the right and the right button's 1-pixel border on the left. See Table 4.1.

Use Succinct Names

The names of command buttons should be succinct and should clearly convey what the command button does. Remember, the user should be able to learn your basic interface in five minutes. That does not leave much time for learning by experimentation. It is best to use standard command names wherever possible so that the user can instantly recognize the button and know its purpose. Table 4.2 lists some of the command buttons found in the built-in applications.

Table 4.2 Common command button names 

Name

Minimum
Width

Description

OK

23

Confirm action and return to previous form

Cancel

36

Revert the current form to the previous settings and return to the previous form

Delete

37

Remove record

Details...

44

Display Details dialog

Done

31

Return to previous form

Edit

25

Edit an existing record

New

27

Create a new record

Note

30

Add a note to a record

Use an ellipsis (...) in the button name if the user must provide more information before the operation is complete. In general, if the button displays a dialog other than an alert, about, or progress dialog, its name should have an ellipsis. The ellipsis can be omitted if you need more space.


TIP: Type three periods instead of using an actual ellipsis character. The character is not available in all fonts.

You can use graphics in the button instead of text (see Figure 4.7). If you keep the graphics small, you can generally fit more graphic buttons on the screen than you can text buttons. However, as with text, the graphic must instantly convey what the button does. On a desktop, application designers often rely on the tool tips feature to teach users what the buttons do. (The user can hover the cursor over the button, and a text box pops up that describes the button.) No such feature exists in Palm OS, so users will have to learn your icons by trial and error.

Figure 4.7  Graphic buttons

Never Dim a Disabled Button

Never dim or gray out a button to show that it does not apply to the current situation. If the button depends on a certain user context, display an alert dialog that explains why the button does not apply. For example, To Do List has buttons at the bottom of the main form that apply to the currently selected task. If the user has not selected an item, tapping one of the buttons results in an alert dialog explaining how to select an item (see Figure 4.8).

Figure 4.8  Alert dialog when button does not apply

If the button depends on certain hardware capabilities, such as the ability to connect to a network, you can test for those capabilities before the form opens and hide the button if it does not apply.

Repeating Buttons

If you want a button to repeatedly perform an action while the user holds down the pen on it, use a repeating button instead of a command button. Use of repeating buttons is relatively uncommon. Two of the more common uses of repeating buttons are:

Figure 4.9  Repeating buttons

Repeating buttons may look exactly like command buttons, but usually the border is removed from a repeating button.

Breaking the Rules ^TOP^

This section points out a few of the applications that break command button guidelines and tells you if doing so was appropriate.

Placing Command Buttons Elsewhere on the Form

If a command button applies only to a particular field on a form, you can place that button next to the field instead of at the bottom of the form. Figure 4.10 shows a form in the SMS Messenger application. In this form, the To command button looks up a phone number in the Address Book. Placing this button next to the field it modifies helps the user understand what the button does. If this button were placed at the bottom of the form, the word "To" would not be a descriptive name for the button. Instead, it would have to be named "Phone Lookup," which still is not as clear as naming the button "To" and placing it next to the field.

Figure 4.10  Command button elsewhere on form

Before breaking the command button guidelines in this manner, consider using a selector trigger in combination with a modal form. The selector trigger could replace the command button and text field. It could display a modal form containing a text field and a list of contacts. Users could either choose a phone number from the list of contacts or write the phone number directly in the text field.

For the SMS Messenger application, a selector trigger is less desirable because it would force people to always use the phone lookup feature. Many people might want to bypass the phone lookup feature if they know a phone number by heart. A selector trigger would not allow for this behavior.

See "Implementing a Combo Box" for further discussion of this style of interface.

Centering Command Buttons

You may notice that every form in Palm OS and its built-in applications has left-aligned command buttons with the exception of about dialogs and progress dialogs (see Figure 4.11). About and progress dialogs each have a single button that is centered on the screen. Do not model any other form after about or progress dialogs. Consistently left justifying buttons is best for the user; the user expects all buttons to appear in a certain location. Note that single-button alert dialogs always left justify the button.

Figure 4.11  Bad example of button placement

Omitting the Ellipsis

The ellipsis character is used inconsistently within the built-in applications. Don't follow what the built-in applications do. Try to follow the ellipsis guideline as it is presented in this chapter: Any button that displays a modal dialog other than an alert, about, or progress dialog should have an ellipsis in its name. The ellipsis should only be omitted if you need to make space.

You may notice that in the built-in applications sometimes omit the ellipsis even when there is room for it (see Figure 4.12).

Figure 4.12  Button that requires ellipsis

The use of an ellipsis on the Delete button also can confuse newcomers to the platform. In general, a Delete command would not have an ellipsis because it displays only a confirmation dialog in response. Many of the Palm built-in applications, however, correctly use the ellipsis on Delete because they do require extra information to complete the operation (see Figure 4.13).

Figure 4.13  Delete confirmation with extra information

Buttons with Nonstandard Height

The Date Book alarm dialog uses buttons that are taller than normal so that users can dismiss the dialog as quickly as possible (see Figure 4.14).

Figure 4.14  Date Book alarm buttons

It's quite common for this dialog to appear and the alarm to sound when the user has the handheld turned off. Users want to dismiss the dialog as quickly as possible and finish what they were doing. The large buttons allow for "finger navigation," enabling virtually all users (not just those with small fingers) to dismiss the dialog without having to get out the stylus.

Use large buttons such as these only if your application has a dialog that is likely to display when the user does not have the stylus out. Once the user has the stylus in his or her hand for some other task, the advantage of the large buttons is lost.

Menus ^TOP^

A menu displays a set of commands that the user can perform (see Figure 4.15). The user either taps the form's title or the Menu icon to display the menu bar, then chooses an item from one of the menus. That command is executed.

Figure 4.15  Menu bar and menu

Table 4.3 Menu details 

Dimension

Value

Width

System determined

Height

System determined

Top

System determined

Left

System determined

Border

Bold rectangle

Content

Adjective or verb that succinctly describes command

System Supplied Behavior ^TOP^

The menu bar is displayed when the user taps either the menu icon or the form's title.

Palm OS ensures the behavior of menus as outlined in Table 4.4.

Table 4.4 Default behavior of menus 

When...

Then...

User drags the pen through the menu

Command under the pen is highlighted

Pen is released over a menu item

That item is selected and the menu bar and menu disappear

Pen is released outside both the menu bar and the menu

Both menu and menu bar disappear and no selection is made

Pen is released in a menu title (Palm OS 3.5 and later only)

Menu bar and menu remain displayed until a selection is made from the menu

Pen is tapped outside menu and menu bar

Both menu and menu bar are dismissed but no event is posted

Menus are fairly simple. Palm OS provides no concept of having a submenu because of the limited screen space. Menus also are not scrollable.

System Displays Last Command Executed

To make it easier for users to perform commonly used commands, the system remembers the last menu item that the user selected (Graffiti shortcuts do not count). The next time the user displays the menu bar, the menu for the previously selected item is displayed and that item is highlighted.

The system only remembers the last menu item as long as the current form is displayed. If a new form is displayed, the current form's menu memory is erased. This means that if the result of the menu item is to display a new form, such as an about dialog, the command is not remembered.

Look and Feel ^TOP^

Follow these guidelines for the behavior and appearance of a menu.

Note that you have no control over the height and width of a menu. The system always determines a menu's boundaries at run time.

Each Form Can Have a Different Menu

Each form can have a menu bar associated with it. (The menu bar is optional; a form does not have to provide menus.) You can provide a different menu bar with a different set of menus for each form in the application.

Provide Options Menu with About Command

Provide an Options menu with an About menu item to display your about dialog. This menu must at least be present on the main form.

If your application has a Preferences dialog, the Preferences command also belongs on the Options menu.

Edit Menu Required for Text Fields

Provide the standard system Edit menu if the form has an editable text field. The Edit menu must look as shown in Figure 4.16. You can add your own items below the last item.

Figure 4.16  Standard Edit menu

Menus Are Static

Keep menus and menu items static. Menu items should not gray or dim when inapplicable. Never remove a menu item nor change its name based on user context. If a menu presents commands that are dependent on certain hardware capabilities and the handheld does not contain those capabilities, hide the menu items before the menu bar is displayed the first time.

Naming Menus and Menu Items

The rules for naming menus and items within menus are similar to those used in desktop applications.

For the menu name, choose a single word that describes the type of items in that menu. Some common menu names:

  • Record—The items are actions performed on the selected database record and can also create and delete records.
  • Edit—The items change the text displayed on the form.
  • Options—The items allow the user to control how the application behaves.

For the menu item name, use either verbs or adjectives. If the item performs an action, use a verb. If the item changes an attribute of an object on the screen, use an adjective. In some cases, it's appropriate to use a noun. Typically, nouns display a dialog with the same name, such as "Preferences." It is particularly important on Palm OS to keep the menu names short. You can manage around 20 characters per item name, but try to keep them much shorter than that. Twenty characters takes up the entire width of the screen, obscuring the entire form.

Use title capitalization in menu items and in all user interface items. That is, capitalize all important words in the item just as you would the title of a book. The menu item for attaching a note, for example, is "Attach Note," not "Attach note."

Use an ellipsis (...) in the menu item if the user must provide more information before the operation is complete. In general, if the item displays a dialog other than an alert, about, or progress dialog, it should have an ellipsis. As with command buttons, type three periods instead of using an actual ellipsis character.

Divider Lines Group Menu Items

If your menu contains a long series of commands (greater than five as a rule of thumb), try to group related commands together with a divider line. In Figure 4.16, you can see the Edit menu uses a divider to separate the usual cut, copy, paste, and undo operations from the menu commands that display the keyboard dialog and that display the Graffiti Help dialog. By providing dividers to group related menu items, you help the user learn and understand the interface. See Figure 4.17.

Figure 4.17  Menu with dividers and without

Menu Shortcuts

A menu shortcut is an alternative to selecting a menu item. Users enter the Graffiti command stroke (a diagonal line drawn upward from left to right) followed by a single character.

This support is present in all versions of Palm OS. In Palm OS 3.5 and later, a command toolbar is displayed. (On earlier releases, just the word "Command" was displayed.) The shortcut toolbar (see Figure 4.18) displays a status message on the left and buttons on the right. After entering the command character, the user has the choice of entering a Graffiti character or of tapping one of the buttons on the shortcut toolbar. Both of these actions cause the status message to be displayed briefly and then cause the corresponding menu item to be executed.

Figure 4.18  Menu shortcut toolbar

There is no requirement to give every menu item a shortcut. Writing Graffiti characters is difficult for many users, and mistakes are common. If the command is destructive (such as Delete), it is better not to provide a shortcut to avoid having the user inadvertently select it. If the destructive command is followed by a confirmation alert, you can assign a shortcut to it.


NOTE: If you assign a shortcut, it must be unique through the entire application, not just the current menu system.

Avoid assigning letters with similar strokes to two different menu items. For example, the Graffiti shortcut for Paste is P rather than the V used on most systems. One reason for this is that the Graffiti stroke for V is similar to the Graffiti stroke for U, which is the shortcut for Undo. It could be detrimental to the users intending to Paste if they instead performed Undo by mistake. Another reason is that most Palm Powered handheld users do not use keyboards with their handhelds, and many may not even know how to type. For keyboard users, the V shortcut for Paste is easy to remember because the V key is right next to the C key. The V shortcut for Paste would not make sense to users who do not know how to type.

Consider Graffiti shortcuts already assigned by other applications when assigning your own Graffiti shortcuts. Make sure that you use the same shortcut if you include the same menu item. This makes the entire system easier for users to learn. Table 4.5 shows the common Graffiti shortcuts used by the built-in applications.

Table 4.5 Common Graffiti shortcuts 

Command

Shortcut

New Record

N

Delete Record

D

Beam

B

Undo

U

Cut

X

Copy

C

Paste

P

Select All

S

Keyboard

K

Graffiti

G

Preferences

R

Buttons on the Shortcut Toolbar

You can include your own buttons on the toolbar for the more commonly executed Graffiti shortcuts (see Figure 4.19). The buttons displayed on the toolbar depend on the user context. If the focus is in an editable field, Palm OS displays buttons for cut, copy, and paste on the shortcut toolbar. If there is an action to undo, the system also displays a button for undo.

Figure 4.19  Toolbar buttons

Only add a button to the toolbar if you define a Graffiti shortcut for that command. Don't arbitrarily add extra buttons to the toolbar.

Limit the buttons displayed on the shortcut toolbar to four or five. There are two reasons to limit the number of buttons. First, you must leave room for the status message to be displayed before the action is performed. Second, consider that the toolbar is displayed only briefly. Users must be able to instantly understand the meaning of each of the buttons on the toolbar. If there are too many buttons, it reduces the chance that users can find what they need.

As described previously, the system already potentially displays four buttons by itself (for cut, copy, paste, and undo). You can suppress this behavior if you feel your users would benefit from seeing other buttons instead.

The system contains bitmaps that represent such commands as beaming and deleting records. If your application performs any of these actions, it should use the system bitmap. Table 4.6 shows the system bitmaps and the commands they represent. If you use any of these, you should use them in the order in which they are listed in Table 4.6, from right to left. That is, BarDeleteBitmap should always be the rightmost of these bitmaps, and BarInfoBitmap should always be the leftmost.

Table 4.6 System shortcut toolbar bitmaps 

Name

Bitmap

Command

BarDeleteBitmap

Delete record

BarPasteBitmap

Paste clipboard contents at insertion point

BarCopyBitmap

Copy selection

BarCutBitmap

Cut selection

BarUndoBitmap

Undo previous action

BarSecureBitmap

Show Security dialog

BarBeamBitmap

Beam current record

BarInfoBitmap

Show Info dialog (Launcher)

Breaking the Rules ^TOP^

This section points out a few applications that break the menu guidelines and tells you if doing so was appropriate.

Including an Exit Command

If you are writing an enterprise application to be used only within a particular company, your users may insist on having an Exit command. These users are used to their desktops, and they feel uncertain about moving from application to application on a Palm Powered handheld.

In this case, it may be best to give your users either an Exit menu command or an Exit command button. Before you do so, make sure they know that when an application is exited (that is, when the system receives an application exit event), the system returns to the last screen displayed before the user launched that application. For most applications, the previous screen is the Launcher because it is used to launch most applications. If your application is launched by one of the hard keys on the handheld, then exiting the application would not always take the user to the Launcher.

Even if your users insist on an Exit command, you should always design your application so that it can be exited in the normal means for a Palm OS application—by pressing one of the hard keys or by tapping the Applications icon—at any time. Consider this a power feature for your users. Your users may use the Exit command at first but will eventually become used to using the other buttons.

Never include an Exit command on an application intended for broad third party distribution.

Nonstandard Menu Names

You do not have to name the first menu "Record" even if it contains items that manipulate a single record in your database. Instead, it is probably better to name it something more familiar to your users. Users are typically not expected to know the terms "record" or "database" as they are used in the Palm OS paradigm. For example, it would probably be better for the "Record" menu in Date Book to be named "Event" and for it to be named "Contact" in Address Book.

Duplicating Menu Items

You may have noticed that the Date Book application violates the rule of not duplicating a command button with a menu item (see Figure 4.20).

Figure 4.20  Menu item duplication

This gives the user several ways to create a new appointment:

  • Tapping the field next to a time and entering the name of the appointment
  • Writing in the Graffiti area (creates an appointment at the specified time if a number is written first or an untimed appointment if a letter is entered first)
  • Tapping the New button, selecting the time, and then entering the name of the appointment
  • Tapping the title bar, choosing the New Event menu item from the Record menu, choosing the time, and then entering the name
  • Entering the Graffiti shortcut for the New Event menu item, choosing the time, and then entering the name

The first two methods of creating a new appointment are somewhat hidden interfaces. Most users catch on that they can simply start writing to create an appointment, but not all users discover this right away. Therefore, some duplication is necessary. Because novice users are the ones most likely to not understand how to enter a new appointment, the New command button (rather than a menu item) is necessary. You cannot provide a menu item and expect novice users to find it because many novice users don't know about the menu. Therefore, the New Event menu item and shortcut are simply redundancies that are probably never used.

Some application designers duplicate commands in the menu so that they can provide a Graffiti shortcut for the command. This is a common practice in desktop applications; however, it is unnecessary for most users of the Palm Powered handheld. Command buttons are placed at the bottom of the form immediately above the Graffiti area. If a command has a button, it is actually more convenient and quicker to tap the button than it is to enter the Graffiti shortcut stroke followed by a letter. Plus, the more shortcuts you provide, the more you risk duplication of shortcut letters.

Do keep in mind, however, that external keyboards have a key that simulates the Graffiti shortcut stroke. This means that users with external keyboards will find a shortcut more convenient than a command button. Therefore, if you have room in your menu, you may want to duplicate a command if it is not one of the standard commands. The external keyboards usually have preassigned keys that simulate taps on the common command buttons, such as New, Delete, Details, OK, and Done, which makes providing a shortcut for these commands unnecessary.