|
Size: 1744
Comment:
|
Size: 1883
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Problem: A decision point is reached, where the user must confirm an action, or choose between a small number of disparate (and usually exclusive) choices. Delete or dont', send an MMS or SMS, etc. Principles/Solutions: 1) Try to avoid these. Except for error or guard conditions (discussed below, LINK) usually can avoid with better design. E.g. opening a Messaging compose screen, instead of asking whether composing an MMS or SMS, just open a compose screen with attachment options. If an attachment is chosen, it becomes an MMS. Else, it's an SMS. 2) When needed, present the choices contextually (usually a modal dialog) simply so it's easy to understand what you are picking and the consequences (e.g. when resizing, why???), and label selections so they can be understood without prior knowledge or reading instructions. E.g. never "yes" "no" buttons, but "delete" or "save" and similar actionable, declarative, free-standing, choices... Handsets are glanceable... the things where you don't label buttons yes or no. Mostly modal dialogues. See wording in Pop-Up about use of SKs (and similar). Use them when available, to keep in style, etc. --> When the device OS uses Softkeys or softkey-like on-screen buttons, there is no need to restrict to only the (usually two) actions available. If additional actions are required, they may be loaded in any way needed, such as buttons in the Pop-Up, as pick lists, etc. Use the Softkeys for primary supporting actions, such as Cancel. Avoid disregarding Softkeys entirely, for consistency of the interface. |
|
| Line 14: | Line 2: |
| A decision point is reached within a process where the user must confirm an action, or choose between a small number of disparate (and usually exclusive) choices. | |
| Line 17: | Line 6: |
| Try to avoid these state. Except for error or guard conditions (discussed below, LINK) usually can avoid with better design. E.g. opening a Messaging compose screen, instead of asking whether composing an MMS or SMS, just open a compose screen with attachment options. If an attachment is chosen, it becomes an MMS. Else, it's an SMS. Sometimes, these cannot be avoided, and user input cannot be divined contextually. If so, present choices contextually, usually as a modal dialogue, simply and with the consequences of the action. |
|
| Line 23: | Line 16: |
| Mostly modal dialogues. label selections so they can be understood without prior knowledge or reading instructions. E.g. never "yes" "no" buttons, but "delete" or "save" and similar actionable, declarative, free-standing, choices... Handsets are glanceable... When the device OS uses Softkeys or softkey-like on-screen buttons, there is no need to restrict to only the (usually two) actions available. If additional actions are required, they may be loaded in any way needed, such as buttons in the Pop-Up, as pick lists, etc. Use the Softkeys for primary supporting actions, such as Cancel. Avoid disregarding Softkeys entirely, for consistency of the interface. |
|
| Line 26: | Line 26: |
| vibrate or beep if it is possible the the things where you don't label buttons yes or no. --- label selections so they can be understood without prior knowledge or reading instructions. E.g. never "yes" "no" buttons, but "delete" or "save" and similar actionable, declarative, free-standing, choices... Handsets are glanceable... |
Problem
A decision point is reached within a process where the user must confirm an action, or choose between a small number of disparate (and usually exclusive) choices.
Solution
Try to avoid these state. Except for error or guard conditions (discussed below, LINK) usually can avoid with better design. E.g. opening a Messaging compose screen, instead of asking whether composing an MMS or SMS, just open a compose screen with attachment options. If an attachment is chosen, it becomes an MMS. Else, it's an SMS.
Sometimes, these cannot be avoided, and user input cannot be divined contextually. If so, present choices contextually, usually as a modal dialogue, simply and with the consequences of the action.
Variations
Interaction Details
Mostly modal dialogues.
label selections so they can be understood without prior knowledge or reading instructions. E.g. never "yes" "no" buttons, but "delete" or "save" and similar actionable, declarative, free-standing, choices... Handsets are glanceable...
When the device OS uses Softkeys or softkey-like on-screen buttons, there is no need to restrict to only the (usually two) actions available. If additional actions are required, they may be loaded in any way needed, such as buttons in the Pop-Up, as pick lists, etc. Use the Softkeys for primary supporting actions, such as Cancel. Avoid disregarding Softkeys entirely, for consistency of the interface.
Presentation Details
vibrate or beep if it is possible the
the things where you don't label buttons yes or no. --- label selections so they can be understood without prior knowledge or reading instructions. E.g. never "yes" "no" buttons, but "delete" or "save" and similar actionable, declarative, free-standing, choices... Handsets are glanceable...
Antipatterns