Softkey and Button Management
From MobileDesign
The native behavior of softkeys varies broadly across devices. Indeed, the second level of the sample hierarchy, just below scroll-and-select, addresses the native treatment of softkeys.
[edit] Design
Where possible, match application softkey behavior with native softkey behavior. For Java ME applications, consider using abstract commands rather than direct control of softkey presentation to simultaneously better match native user interface and have fewer design decisions.
Of course consistency throughout the application is equally important. Use standard interaction design practices throughout.
[edit] Nokia-style softkeys
Make the left softkey be "Options." All actions available to the currently highlighted item as well as the entire screen should be items within the Options menu.
The right softkey should be "Back," "Cancel," or "Quit," (or something similar) depending on context. Assume that the use of the right softkey will be overridden during text entry.
In certain very simple wizard-like applications, the left softkey can be forward/select, and the right softkey can be back/quit. These applications are rare.
If the device and platform has access to an End key, assign the Exit action to that key. Also provide exit functions from the application's main menu and major places within the application. If the device has no End key, add Exit to the list of controls to be allocated between the Options menu and the screen.
[edit] Samsung-style semi-softkeys (left button hardware labeled "OK," right hardware labeled "Menu")
Assign the most common backward navigation function to the Back button. Assign the most common action associated with individual items, especially "View" or equivalent, to the left softkey.
Assign all other controls either to a combination of the right softkey (labeled "Menu") and on-screen objects.
If the device and platform has access to an End key, assign the Exit action to that key. Also provide exit functions from the application's main menu and major places within the application. If the device has no End key, add Exit to the list of controls to be allocated between the right softkey and the screen.
[edit] "Standard" (undedicated) softkeys with Select and Back buttons
Assign the most common backward navigation function to the Back button. Assign the most common action associated with individual items, especially "View" or equivalent, to the Select button.
Assign the most common item for the entire screen, such as "Save," "Assign," "Next," or similar, to the left (primary) softkey. If no screen item is available, instead choose a secondary item-based action.
Assign all other controls either to a combination of the right softkey (labeled "Menu") and on-screen objects.
If the device and platform has access to an End key, assign the Exit action to that key. Also provide exit functions from the application's main menu and major places within the application. If the device has no End key, add Exit to the list of controls to be allocated between the right softkey and the screen.
[edit] "Standard" (undedicated) softkeys with Select and Back buttons ... and with Talk/Send on the right side of the device.
Same as Standard, but have the primary softkey be the right softkey.
Devices that have made the decision to put the Send key on the right and the End key on the left generally have all backward navigation on the left and forward or primary navigation on the right.
[edit] Applicable Devices and Platforms
Any environment with control over softkeys. The most notable exceptions are web browsers and text messages.
[edit] When Used
Softkey management is a key component of the information architecture and interaction design of an application. Its strategy should be an early decision, and exact use will be a decision made for each screen and perhaps each selectable item.
[edit] Rationale
Certainly softkeys provide a dynamic label for an action that can be readily viewed by the user. While it may seem that this suggests that users can quickly learn the action of the softkeys, evidence does not show this to be true.
A user accustomed to a Nokia device, with Back and Cancel assigned to the right softkey, may never find the hardware Back button. Indeed, some applications have been reviewed and criticized for having no back function. A user of a non-Nokia device might be able to find the Back function on the softkey, but is likely to attempt to use the hardware Back button several times even after the application is will learned.
A user with a device with a dedicated Select button will almost certainly have ongoing issues with a Select function applied to a softkey. The press-OK behavior is deeply ingrained.
The standard Nokia implementation of the left softkey being used as "Options" along with the right softkey as "Back" can be mapped onto any device with two or more softkeys. Unfortunately this interface makes no sense to non-Nokia users. Users may think that "Options" refers to application Options. The interface simply does not appear to have any function.
User interfaces that presume separate Back and Select buttons, on the other hand, may not work at all on Nokia devices.
While there are similar differences between Samsung and Motorola RAZR user interfaces, more designers and developers make the Nokia assumption than any other. For example, J2ME Polish prior to version 2.0 only supported a Nokia user interface or explicit softkey management.
Also see: Any that apply, Else remove it entirely
