How Soft Can a Key Be?

Softkey is not just a key, but a construct with several user interface elements:

1. The key which launches the action when pressed

2. The variable softkey label, which identifies the action in a context-dependent manner

3. The subject of the current softkey action, which is typically an active selected menu item^[*]

For the softkey concept to be understandable, users need to figure out the meanings and the relationships between the elements. Easy as it might sound, the softkey concept is not without a few inherent usability problems.

• Associating the key with the label. When we first introduced the concept of softkey, novice users had trouble matching the physical softkey with the label displayed. For some users these problems weren’t especially serious, but the observation is unquestionable nonetheless. Typically users are able to overcome this problem and adapt to the softkey UI with practice. It probably arises in the first place because certain users perceive screens and keypads as different domains of the user interface, and find it hard to comprehend UI elements that are logically one thing, but exist in two domains. We have tried with various visual elements to link the screen and keypad parts of the softkey together, but close proximity of the two has turned out to be the most effective way of doing it.

• Ignoring softkey texts. While our colleagues at NASA were able to rely on the moon explorers to remember dozens of artificial number codes, we cannot count on today’s highfliers to read both of the two words presented to them in their mother tongues on the screens of their devices. When reading menu texts, users tend to ignore softkey texts. When browsing lists, users pay attention to the items on a list but overlook the softkey labels. It’s quite common for users to press a softkey without actually reading the label at all, which can lead to errors. What’s the upshot of this behavior? On one hand, we strongly require that the meaning of the softkey in each situation approximate the user’s expectations. That requirement is best met with a consistent design, rather than an extremely context-sensitive one. On the other hand, keeping the softkey static disregards the dynamic and context-dependent potential of the concept. The power of the concept is lost if we can’t associate the softkey with the most likely inputs in each situation. Softness has its limits. Only careful design and testing can lead to the best softkey solutions.

• The priority of the primary function. The one-softkey style, Navi-key, with its four control keys appears to be a good solution for many simple tasks, but it calls for simple designs overall. When designers can assume that the user wants to perform just one type of action in a given situation, that action can be assigned to the only softkey, and the user should have an easy time of accomplishing the task. But whenever more than one action is available to the user, the softkey has to be labeled as options. Any number of actions can then be collected into the options list, but now none of them is accessible by a single key press, which slows down the interaction. It also partly ruins the rationale of the concept. This tradeoff shows in the design of the phonebook. In a one-softkey UI, there is no dedicated send key, and for efficiency the softkey is assigned as “call” when the names list is being browsed. Accordingly, number editing or other actions are not available at all in this state. Such a function has to be selected before starting to browse the name list. In other words, instead of choosing a name and deciding what function to apply, the user chooses an operation and finds someone to do it to. The principle of maintaining consistency in the object-action sequence throughout the user interface has been broken here to allow more intuitive access to the most important function.

• Screen area challenge. When the length of menu item text becomes a problem, it will be even more of a problem for softkey labels. One short word has to be found in all languages for all softkey texts. Icons would save us space, but the requirement for easy interpretation has been shown to favor text labels.

^[*]The softkey concept does not require the existence of a corresponding menu item. For instance, the idle screen has softkeys but no corresponding elements of this kind. However, softkeys in Nokia menus are typically applied by linking softkey labels and menu items, and the link explains many of the usability problems related to softkeys.