|
Size: 372
Comment:
|
Size: 1883
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Maybe Principles ... but the thing 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. |
|
| Line 5: | 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 8: | 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 14: | 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 17: | 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