Differences between revisions 7 and 8
Revision 7 as of 2011-03-25 01:29:55
Size: 3424
Editor: shoobe01
Comment:
Revision 8 as of 2011-03-25 01:46:01
Size: 4260
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 36: Line 36:
unambiguously label on key... must be visible in all conditions The key must be unambiguously labeled with the function. Volume keys may get a pass as they are expected, so any single key pair may be understood to be volume controls. However, the difference between the camera and power buttons -- for example -- should be made clear by labels.
Line 38: Line 38:
labels and descriptions for on-screen effects, notifiers, etc. must comply with the hardware label. Labels should be visible in all conditions. See the '''[[Mode Switches]]''' pattern for additional details on this, and especially for risks of backlight under certain lighting conditions.

labels and descriptions for on-screen effects such as notification icons should comply with the hardware label to draw a clear parallel between the two.


Key position should considered for
Line 45: Line 50:
Do not cast labels into keys without highlighting with color and/or providing a backlight. Impressed keys labels are unreadable under all but the best lighting conditions, and will not be understandable by the user.

Do not make up new symbols to denote key functions. Use common, universally-recognized icons or other labels.

Softkeys, lock/power, volume, etc. Mostly that they need to press in or be clearly of a different shape to afford, must light up like keypads, must be labeled unambiguously and the label must light up, must be near labels which means SKs need to not be 5 feet from the screen, etc.

Problem

Solution

Outside of Keyboards & Keypads and Directional Entry controls, practically all mobile devices have numerous additional keys. Regardless of their function, all must comply with some basic behavioral standards in order to be useful, usable and valuable to the user.

Variations

There are two basic types of hardware keys, based on their effect.

  • Hardware -- The key affect is to device hardware. Any on-screen, interactive display is incidental to the function. These are functions like volume, and radio toggles.

  • Interaction -- The key affect is only to interactive, software driven elements, generally resulting in a principle, unmistakable interaction. Back, search or camera keys are representative of this type.

In either case, the attributes and behaviors discussed in this pattern are applied in the same manner.

Interaction Details

The use of any hardware key must have an immediate, noticeable response, regardless of the type of function being performed. This applies even if the action takes some time to take effect, such as time to load the camera application.

There should always be a visible effect. Generally, this should be an on-screen display of some sort. If the primary effect is either not an interactive element, or cannot be launched within about 1/10th of second, and secondary display must be used. Though many options are available, some frequently-used variations are:

  • Pop-up dialogue, sometimes a variation which is for display only, has no opaque bounding box or background field, and cannot be interacted with.

  • Annunicator or other notification indication. An icon can be added, or change in an obvious manner.
  • Pre-launch the application. If camera hardware takes a few seconds to load, the camera application can still begin launching immediately, and open in a state that indicates this delay.

Pop-Ups will generally disappear after a few seconds. Annunicators may need to remain in place, to indicate the change of state permanently, such as enabling Bluetooth features, which displays the Bluetooth icon in the Annunicator Row.

Direct responses should also be used when technically feasible. If individual-key backlight is available, the backlight should dim momentarily during keypress. Rarely, this may be used successfully as an indicator with all key backlighting changing based on certain keypresses.

Haptic or audio responses are also valuable as a way for the user to confirm the key has been activated, or for multi-step keys (such as volume) to give a better sense of the number of steps entered. Subtle clicks, whether through vibration or the speaker, can serve this need.

Presentation Details

The key must be unambiguously labeled with the function. Volume keys may get a pass as they are expected, so any single key pair may be understood to be volume controls. However, the difference between the camera and power buttons -- for example -- should be made clear by labels.

Labels should be visible in all conditions. See the Mode Switches pattern for additional details on this, and especially for risks of backlight under certain lighting conditions.

labels and descriptions for on-screen effects such as notification icons should comply with the hardware label to draw a clear parallel between the two.

Key position should considered for

Make on-screen stuff about it adjacent to the key whenever possible; can even point to it for help or tutorials...

Antipatterns

Do not cast labels into keys without highlighting with color and/or providing a backlight. Impressed keys labels are unreadable under all but the best lighting conditions, and will not be understandable by the user.

Do not make up new symbols to denote key functions. Use common, universally-recognized icons or other labels.

Examples

Other Hardware Keys (last edited 2011-07-31 23:13:42 by shoobe01)