Differences between revisions 2 and 3
Revision 2 as of 2010-11-03 19:40:03
Size: 372
Editor: shoobe01
Comment:
Revision 3 as of 2010-11-03 21:29:46
Size: 1744
Editor: shoobe01
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. 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.

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.

Problem

Solution

Variations

Interaction Details

Presentation Details

Antipatterns

Examples

Confirmation (last edited 2013-04-11 00:01:00 by shoobe01)