Most mobile devices are still centered around voice networks connected to the PSTN. You may have to provide access to a phone dialer.
The dialer is provided with devices, but you may have to recognize and enable phone numbers to launch the dialer. Voice communications outside of the voice network, using various VoIP implementations, also opens the possibility of building part or all of a phone dialer into other products.
Numeric entry for this dialer application or mode varies from other entry methods, and has developed common methods of operation that users are accustomed to. You have to follow these standards to provide easy access to the voice network. There are also notable technical requirements, and failing to address those -- even at the interface design level -- will make it difficult or impossible to accurately connect.
This pattern is concerned with only the numeric entry and certain aspects of the overall interaction of the Dialer application. Numerous additional features and details of the operation are not discussed here, largely for space concerns. Follow the guidelines from the operator, especially as they regard specifics of the network, local regulatory requirements, and interoperability needs.
For most of the history of mobile devices, telephony was the key feature, and was integral to the device at all levels. This is still the method employed for almost all devices with a dedicated numeric keypad. From the Home & Idle Screens keypad entry will result in switching to the Dialer mode, and the entered character being typed onto the screen.
In these cases, the Dialer application does not need to be deliberately activated as the handset is considered a phone when not otherwise engaged. Naturally, when in other applications, the keypad is used for text or numeric entry within that context, or to activate Accesskeys and does not immediately launch the Dialer.
A variation employed first by "PDA phones" and now by most smartphones is to make the Dialer just another application on the device, with few or no special UI conditions. In these cases, dialing cannot be initiated directly from the Idle screen. The Dialer application must instead be deliberately launched before any characters can be entered.
The Dialer application is very often closely coupled with -- or a part of -- address books, call history and other features. However, only the Dialer itself will be discussed here.
When users enter characters, they will appear in the phone number field, which is generally near the top of the viewport. Character entry is much as any other text entry, with a cursor, and the ability to delete characters using the "back" or "delete" function. If the handset does not include a hardware back or backspace button, you will need to provide it on the screen, usually next to the input field itself.
Display any matching results below the numeric entry field. Matching is the practice of providing extended information about the number entered so far. A live search of the address book will be performed as characters are typed. Users may select from the list displayed, or simply confirm that the dialed entry is correct.
For example, if the characters "210" are entered, the following items (already in the address book) may be listed:
- Jane Adams 816 210 0123
- Dee Adler 210 618 0567
All typed characters are always entered into the phone number field, and the matching results are in a separate space. This is the "suggestion" variant of the Autocomplete & Prediction pattern, which see. This generally results in a "split focus" where vertical scrolling changes the item in focus in the match list, and horizontal scroll changes position in the entry panel. Pressing "Talk" will dial the last selected number; if the last entry is scrolling, an item in the match list, if the last entry is typing (or scrolling up and out of the list) then the entered value.
If no address book match is found, then you should display the region (such as the U.S. state) that corresponds to the number format. For example, as soon as "816" is typed, with no matches, "Missouri" may be displayed (as this area code is entirely within that U.S. state). This will increasingly be troublesome, as mobile phones allow the handset to physically be anywhere, and number portability allows any number to be associated with any region. My phone, for example, indicates it is from Missouri, but I live in Kansas now, and routinely am far from there.
Errors and null-value information will not be displayed when address book or regional matching is not available or not found. Instead, you simply display no matches at all.
Pressing the "Talk" button is generally required to dial a call or select a match from the list.
There is no significant variation for the use of a virtual, on-screen keypad. When visible, the same behaviors take place. Virtual keypads are usually presented as only one of several options, so may not be available by default when the Dialer application is open, or when a call is initiated or received. Easy and unambiguous access to the keypad must be provided at all times.
If the user presses and holds a numeric key, this will initiate a shortcut and dial the corresponding number. If no shortcut is assigned, no special action should be taken and no errors displayed. The key will simply be entered as though a short-press was performed.
The shortcut character should appear on the screen, to confirm it has been entered. These may display inside the phone number field (usually with a special character to indicate the difference, such as a preceding pound) or may be displayed in a different manner, such as a momentary overlay.
The 1 key is most often reserved for voicemail, though this may vary based on operator standards.
Whenever a call is active --- whether sent or recieved -- a version of the Dialer is generally made available in order to allow selection of extensions or entering information in IVR (interactive voice response) systems. The same principles will be followed as in the dialer, with keypad entry displayed immediately. The tones will also be sent over the network immediately. The display should show all numbers entered since the original connected number. Do not display these additional values appended to the dialed number, as it will become a long, nonsensical string so hard to decipher.
Whenever possible, increase the time that screen backlight is entirely removed while in calls, in order to allow the user to see the current state of an ongoing call without handing the device. Use sensors, as described in the Kinesthetic Gestures pattern, to automatically lock the screen or keypad, and turn on and off the backlight, to reduce battery use or prevent unintended input.
The Dialer screen will be fixed, with elements remaining in the same location and always visible. Selectable items which must scroll (such as name matches) will do so only within a small area and will not scroll the entire page. The number pad itself must never scroll off the page.
The number entered must display in a common, readily recognized format for the locale. In the U.S. this would mean the characters 8162100455 display as 816-210-0455, for example. Avoid wrapping the primary number to a second line; if needed due to space, break at the end of the dialed number so that extensions and IVR entries are on the second (and third...) lines. Format characters are only for appearance, and cannot be edited directly by the user; they will disappear before they can be scrolled to.
Special functions for use while the call is active, such as mute, and speaker may be presented as on-screen buttons for touch or pen devices. Whenever possible, display these alongside virtual keypads instead of requiring switching from keypad to control mode.
Additional functions, such as 3-way calling should be placed under options menus, such a Softkeys. The exact implementation will vary depending on the OS standards of the device. Avoid hiding important and frequently used in-call features, such as mute, speakerphone and headset controls under options menus, even for scroll-and-select devices. Avoid placing these functions only on hardware keys, especially if the labels are small, not illuminated or the keys are on the side of the device. Place these functions on-screen whenever possible. Feel free to provide informational graphics to indicate where a hardware key can be found that provides the same function.
Display the current state of the device when on a call. The time on call, connected status and audio features (mute, speaker, headset) should be clearly visible on the screen, without scrolling or searching inside options menus.
Keys must be clearly labeled, and must comply with the layout and labeling of the local region. While innovative layouts or graphic design may be used to differentiate the product, the user must be able to dial the handset without undue difficultly. Secondary key labels -- discussed in the Keyboards & Keypads pattern for their use in multi-tap entry methods -- are originally and still used as mnemonic shortcuts for dialing, and must also comply with the locale in which the device is to be used.
When the Dialer is displayed for address book entry, formatting hints or optional entry methods should be provided. Hard pause, soft pause and international dialing codes are not directly supported by the numbers on the keypad, so will require special methods (such as menus or custom buttons) or informing the user of keypad shortcuts.
Characters entered must be typed immediately and each character entered as typed. Do not require a "wake-up" character to open the Dialer but then be ignored, even if all subsequent characters are entered correctly.
Do not include un-necessary functions. For example, pause characters are not needed when live dialing, just when saving entered information to the address book.
Avoid hiding virtual keypads behind ambiguous labels. Whenever practical, place a "Keypad" button, with a suitable iconic label, on the screen or as a primary Softkey.
The OK/Enter button should not perform unexpected or out-of-domain functions. For example, when selecting a match from the list, it should either dial or display additional options. However, a default condition (or pressing the Talk key from here) should dial the call. Loading the address book would be confusing and make it difficult for the user to dial the call quickly and without error.
Do not require the user to dial using PSTN standards when they can be deciphered and solved. In the US, you must dial 1 before the area code for calls outside the local area, but may not dial the 1+ area code for local calls (from and to numbers in the same area code). Even if the mobile network is not intelligent enough, make the handset software interpret any dialed number so it does not display these simple errors, and sends the appropriate codes. Never allow the user to hear a voice saying "Please dial a one or zero to complete this call..."
Next: On-screen Gestures
Discuss & Add
Please do not change content above this like, as it's a perfect match with the printed book. Everything else you want to add goes down here.
If you want to add examples (and we occasionally do also) add them here.
Make a new section
Just like this. If, for example, you want to argue about the differences between, say, Tidwell's Vertical Stack, and our general concept of the List, then add a section to discuss. If we're successful, we'll get to make a new edition and will take all these discussions into account.