Differences between revisions 13 and 24 (spanning 11 versions)
Revision 13 as of 2010-11-05 17:08:51
Size: 7804
Editor: shoobe01
Comment:
Revision 24 as of 2013-04-11 00:01:00
Size: 11911
Editor: shoobe01
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
{{{#!html

<div class="saleshead">
    <div class="block" id="left">
        <a href="http://4ourth.com/wiki/4ourth%20Mobile%20Touch%20Template">
        <div class="salesLeft">
           <h3>4ourth Mobile Touch Template</h3>
           <p>Design for people, not pixels with this handy, wallet-sized inspection and design tool, only $10. <span>Order yours now</span></p>
        </div>
        </a>
    </div>
    <div class="block" id="right">
        <a href="http://4ourth.com/wiki/Mobile%20Design%20Patterns%20Poster">
        <div class="salesRight">
           <h3>Mobile Interaction Design Patterns Poster</h3>
           <p>Every pattern from the book and this wiki, plus easy-to-follow relationships, and key information on sizes for readability and touch. <span>Order now</span></p>
        </div>
        </a>
    </div>
    <div class="salespad">&nbsp;
    </div>
</div>

}}}


Line 2: Line 29:
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. You have created a process which includes points where the user must confirm an action, or choose between a small number of disparate (and usually exclusive) choices.

'''Confirmation''' steps are simple, logical parts of many processes, and can be easily implemented in any number of ways. These patterns discuss the best ways to do so on mobile devices.
Line 7: Line 36:
Try to avoid presenting these conditions to the user. Except for error or guard conditions such as '''[[Exit Guard]]''' systems can often be designed for avoid explicit choices. For example, when opening a Messaging compose screen, instead of presenting a '''Confirmation''' dialog asking whether they intend to compose 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. The choice is still made by the user, but implicitly by actions and choices (selection of the attachments) they needed to make anyway. Whenever possible, you should use information from current and previous user behavior, sensors and any other sources, to try to present the correct option to the user. When that is not possible, or likely, present the most likely choice, and give options to switch to others.
Line 9: Line 38:
Sometimes, these cannot be avoided, and user input cannot be divined contextually. If so, present choices contextually -- usually as a modal dialogue -- simply and clearly communicate the consequences of the choices. For example, when opening a Messaging compose screen, instead of presenting a '''Confirmation''' dialog asking whether they intend to compose 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. The choice is still made by the user, but implicitly by actions and choices (selection of the attachments) they needed to make anyway.

Except for error or guard conditions such as '''[[Exit Guard]]''', systems can often be designed for avoid explicit choices.

When the step cannot be avoided, and user input cannot be divined contextually, then you must present the choices contextually, as choices related to the task or screen that preceded the '''Confirmation''' screen. Always communicate the consequences of the choices simply and clearly.
Line 15: Line 48:
{{attachment:Confirmation-Single.png|Single choice Confirmation dialogues are rare, but important variations. When the user must be notified of something they cannot alter, but which will effect them, such as a dropped call or frozen system, informing the user even when they have no choice is better than not telling them at all.|align="right"}} {{attachment:Confirmation-Single.png|Single choice Confirmation dialogues are important variations. When the user must be notified of something they cannot alter, but which will effect them, such as a dropped call or frozen system, informing the user even when they have no choice is better than not telling them at all. Processes that require a Wait Indicator widget will also often be in Confirmation dialogues, either with a "Cancel" button as shown here, or without.|align="right"}}
Line 17: Line 50:
A '''single choice''' is only used to inform the user. For example, a fatal error has occurred, and the handset must be restarted. Instead of just doing it for them without warning, it may be helpful to tell the user that the condition has been reached, so you should present a '''Confirmation''' dialogue, with a single "Restart" button. In cases where the condition is not catastrophic (such as a dropped call) you may choose to have the dialogue disappear after a brief time. Including a button then simply allows the user to dismiss the dialogue that much faster.
Line 18: Line 52:
A '''single choice''' is fairly rare, and is only used to inform the user. For example, a fatal error has occurred, and the handset must be restarted. Instead of just doing so, it may be helpful to tell the user that the condition has been reached, so a '''Confirmation''' dialogue is presented, and a single "Restart" button is presented. In cases where the condition is not catastrophic (such as a dropped call) the dialogue may disappear after a brief time. The button then simply dismisses the dialogue that much faster. Some other method (such as loading the call log, and displaying the "dropped call" icon) should present the same message after the dialogue times out. When you automatically dismiss messages, it is usually best to have some other method display the same message. Load the call log, with the item visible, or add an item to the '''[[Notifications]]''' area. You can determine the best method by examining the OS or application standards.
Line 20: Line 54:
By far the most common is '''two or three choices'''. This is the maximum number readily comprehended at a glance and presents enough options for most required decisions. Examples of three choices are when exiting with unsaved documents, offer to return to work, save the work and exit and exit without saving. See '''[[Exit Guard]]''' for more discussion of these sorts of conditions. A variant of the single choice includes a '''[[Wait Indicator]]''' to denote that a process -- usually a user-initated one -- has begun and they must wait to perform other tasks. When possible, include a "Cancel" button. If not, this may become a sort of "no choice" confirmation box, with nothing but messaging and the '''Wait Indicator''' widget in a '''[[Pop-Up]]'''.
Line 22: Line 56:
In some cases, a '''larger number of choices''' must be presented. These will generally be as a list of selections in the dialogue. By far the most common is the "two or three choices" variant. This is the maximum number of choices that a user can readily comprehended at a glance, while also presenting enough options for most required decisions. Examples of three choices are when exiting with unsaved documents:
 * Keep working on the document
 * Save the document and exit
 * Exit without saving the document
Though these are not ideal labels. See '''[[Exit Guard]]''' for more discussion of these sorts of conditions.

In some cases, a larger number of choices must be presented. These will generally be offered as a single '''[[Select List]]''' in the dialogue. Avoid scrolling, but this may be unavoidable.
Line 26: Line 66:
{{attachment:Confirmation-FloatOrNot.png||align="right"}}
The '''Confirmation''' pattern involves an error or choice that stops the process. Such choices should not be avoidable, but should be contextual to make it clear what application, or process they will effect. These should therefore be modal '''[[Pop-Up]]''' dialogues almost always. See that patterns for additional details.
{{attachment:Confirmation-FloatOrNot.png|For devices with Softkeys, or Softkey-like buttons, there are two methods of presenting the Pop-Up. It may be floating, and the lack of graying out of the buttons and Pop-Up relate them, or it may be anchored to the same edge as the buttons, to tie them together more strongly.|align="right"}}
The '''Confirmation''' pattern involves an error or choice that stops the process. Such choices should not be avoidable, but should be contextual to make it clear what application, or process they will effect. These should therefore be modal '''[[Pop-Up]]''' dialogues almost always. See that pattern for additional details.
Line 29: Line 69:
Whether two or three choices is convenient or requires a non-standard UI is dependent on the OS paradigms. When the device OS uses Softkeys or softkey-like on-screen buttons, then two choices with the dialogue docked to the edge with the buttons is the simplest way to present a small number of options. However, it (usually) limits the options to two. Whether two or three choices is convenient or requires a non-standard UI is dependent on the OS paradigms. If the device OS you are designing for uses Softkeys or softkey-like on-screen buttons, then two choices with the dialogue docked to the edge with the buttons is the simplest way to present a small number of options. However, it (usually) limits the options to two.
Line 31: Line 71:
If additional selections 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. In the example above of exiting with unsaved documents, the choices to exit without saving and save documents would be in the dialogue, and the option to return to the application would be labeled "Cancel" and be the Softkey conventionally used for this. If additional selections are required, they may be loaded in any way needed, such as buttons in the Pop-Up, as pick lists, etc. Use any Softkeys or on-screen buttons for primary supporting actions, such as Cancel. In the example above of exiting with unsaved documents, the choices to exit without saving and save documents would be in the dialogue, and the option to return to the application would be labeled "Cancel" and be the Softkey conventionally used for this.
Line 33: Line 73:
Avoid disregarding Softkeys entirely, for consistency of the interface. When working with such devices, avoid disregarding Softkeys entirely, for consistency of the interface.

When designing for other interfaces, especially for touch and pen input, selections should usually be buttons.
Line 39: Line 81:
{{attachment:Confirmation-Detailed.png||align="right"}}
If the '''Confirmation''' action occurs while an application is running in the background, use any available notification method installed with the OS to bring this to the front. If the only method is a '''[[Pop-Up]]''' dialogue interrupting the in-focus process, use this carefully. Trivial processes, such as a game crashing, do not need to interrupt phone calls.
{{attachment:Confirmation-Detailed.png|The title, description and button labels must work independently and in concert to make the Confirmation dialogue clear and immediately obvious to the user.|align="right"}}
If the '''Confirmation''' action occurs while an application is running in the background, use any available notification method installed with the OS to bring this to the front. If the only method is a '''[[Pop-Up]]''' dialogue interrupting the in-focus process, use this carefully. Trivial processes, such as your game crashing, do not need to interrupt phone calls.
Line 42: Line 84:
The Title of the dialogue must clearly denote the choice to be made. Do not label it as "Error," with codes or jargon, or with the name of the parent application. For the example used above of exiting with unsaved work, "Unsaved work" would be a suitable title. The '''[[Title]]''' of the dialogue must clearly denote the choice to be made. Do not label it as "Error," with codes or jargon, or with the name of the parent application. For the example used above of exiting with unsaved work, "Unsaved work" would be a suitable title.
Line 46: Line 88:
Button labels must not depend on the description or title. Never present selections such as "Yes" and "No." At the same time, do not let options be too long, or they may not be readable, or may not look like selections. Options like "Delete" and "Save" are much more suitable. For the same example used previously, options might be: Button labels must not depend on the description or title. Never present selections such as "Yes" and "No." Do not try to fix these by adding a question such as "Save these changes?" Users will not read the whole thing, but just glance at the options, and will become confused by your vague buttons.

At the same time, do not let options be too long, or they may not be readable, or may not look like selections. Options like "Delete" and "Save" are much more suitable. For the relatively complex example used previously, options might be:
Line 51: Line 95:
{{attachment:Confirmation-LongList.png||align="right"}} {{attachment:Confirmation-LongList.png|In rare cases, more options than can be fit on the screen must be presented. In this case, a scrolling selection box may be offered instead. This is not glanceable, so should be avoided.|align="right"}}
Line 58: Line 102:
Do not over use the '''single choice''' variation. For example, if an application must quit and a '''Confirmation''' dialogue is useful, a dual choice would usually be better. Offer options to just quit or to quit and restart the same application immediately. Reduce clicks whenever possible. When a selection is made, it should immediately commit the change and proceed to the next step. Never force the user to make the choice, then press some sort of "Submit" button.

Do not over use the "single choice" variation. For example, if an application must quit and a '''Confirmation''' dialogue is useful, a dual choice would usually be better. Offer options to just quit or to quit and restart the same application immediately.
Line 67: Line 113:

----
Next: '''[[Sign On]]'''
----
= 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.
Line 68: Line 121:
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.

Problem

You have created a process which includes points where the user must confirm an action, or choose between a small number of disparate (and usually exclusive) choices.

Confirmation steps are simple, logical parts of many processes, and can be easily implemented in any number of ways. These patterns discuss the best ways to do so on mobile devices.

For Confirmation dialogues, the process is interrupted to present a series of choices. For touch and pen devices, arrangements like this, with stacked buttons, are common and easy to understand.

Solution

Whenever possible, you should use information from current and previous user behavior, sensors and any other sources, to try to present the correct option to the user. When that is not possible, or likely, present the most likely choice, and give options to switch to others.

For example, when opening a Messaging compose screen, instead of presenting a Confirmation dialog asking whether they intend to compose 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. The choice is still made by the user, but implicitly by actions and choices (selection of the attachments) they needed to make anyway.

Except for error or guard conditions such as Exit Guard, systems can often be designed for avoid explicit choices.

When the step cannot be avoided, and user input cannot be divined contextually, then you must present the choices contextually, as choices related to the task or screen that preceded the Confirmation screen. Always communicate the consequences of the choices simply and clearly.

Variations

Though many display methods are possible, all will be modal dialogues of some sort. For more details on these, see variations under Pop-Up.

Single choice Confirmation dialogues are important variations. When the user must be notified of something they cannot alter, but which will effect them, such as a dropped call or frozen system, informing the user even when they have no choice is better than not telling them at all. Processes that require a Wait Indicator widget will also often be in Confirmation dialogues, either with a "Cancel" button as shown here, or without. Three key variations exist: A single choice is only used to inform the user. For example, a fatal error has occurred, and the handset must be restarted. Instead of just doing it for them without warning, it may be helpful to tell the user that the condition has been reached, so you should present a Confirmation dialogue, with a single "Restart" button. In cases where the condition is not catastrophic (such as a dropped call) you may choose to have the dialogue disappear after a brief time. Including a button then simply allows the user to dismiss the dialogue that much faster.

When you automatically dismiss messages, it is usually best to have some other method display the same message. Load the call log, with the item visible, or add an item to the Notifications area. You can determine the best method by examining the OS or application standards.

A variant of the single choice includes a Wait Indicator to denote that a process -- usually a user-initated one -- has begun and they must wait to perform other tasks. When possible, include a "Cancel" button. If not, this may become a sort of "no choice" confirmation box, with nothing but messaging and the Wait Indicator widget in a Pop-Up.

By far the most common is the "two or three choices" variant. This is the maximum number of choices that a user can readily comprehended at a glance, while also presenting enough options for most required decisions. Examples of three choices are when exiting with unsaved documents:

  • Keep working on the document
  • Save the document and exit
  • Exit without saving the document

Though these are not ideal labels. See Exit Guard for more discussion of these sorts of conditions.

In some cases, a larger number of choices must be presented. These will generally be offered as a single Select List in the dialogue. Avoid scrolling, but this may be unavoidable.

Interaction Details

For devices with Softkeys, or Softkey-like buttons, there are two methods of presenting the Pop-Up. It may be floating, and the lack of graying out of the buttons and Pop-Up relate them, or it may be anchored to the same edge as the buttons, to tie them together more strongly. The Confirmation pattern involves an error or choice that stops the process. Such choices should not be avoidable, but should be contextual to make it clear what application, or process they will effect. These should therefore be modal Pop-Up dialogues almost always. See that pattern for additional details.

Whether two or three choices is convenient or requires a non-standard UI is dependent on the OS paradigms. If the device OS you are designing for uses Softkeys or softkey-like on-screen buttons, then two choices with the dialogue docked to the edge with the buttons is the simplest way to present a small number of options. However, it (usually) limits the options to two.

If additional selections are required, they may be loaded in any way needed, such as buttons in the Pop-Up, as pick lists, etc. Use any Softkeys or on-screen buttons for primary supporting actions, such as Cancel. In the example above of exiting with unsaved documents, the choices to exit without saving and save documents would be in the dialogue, and the option to return to the application would be labeled "Cancel" and be the Softkey conventionally used for this.

When working with such devices, avoid disregarding Softkeys entirely, for consistency of the interface.

When designing for other interfaces, especially for touch and pen input, selections should usually be buttons.

Presentation Details

When the Pop-Up appears, use other methods to notify the user of the stop in process, such as audio and/or vibration. Follow current system volume settings for the notification. Mobiles are used in quick glances, so the user may not notice such a stop in process for minutes or hours unless informed via a non-visual channel.

The title, description and button labels must work independently and in concert to make the Confirmation dialogue clear and immediately obvious to the user. If the Confirmation action occurs while an application is running in the background, use any available notification method installed with the OS to bring this to the front. If the only method is a Pop-Up dialogue interrupting the in-focus process, use this carefully. Trivial processes, such as your game crashing, do not need to interrupt phone calls.

The Title of the dialogue must clearly denote the choice to be made. Do not label it as "Error," with codes or jargon, or with the name of the parent application. For the example used above of exiting with unsaved work, "Unsaved work" would be a suitable title.

A description should usually be provided. If the choices are clear or simple enough, this may sometimes be left out. For the same example a suitable description would be "You have chosen to exit but have made changes to files without saving." The description and title may or may not be questions, as the choices will often serve this role.

Button labels must not depend on the description or title. Never present selections such as "Yes" and "No." Do not try to fix these by adding a question such as "Save these changes?" Users will not read the whole thing, but just glance at the options, and will become confused by your vague buttons.

At the same time, do not let options be too long, or they may not be readable, or may not look like selections. Options like "Delete" and "Save" are much more suitable. For the relatively complex example used previously, options might be:

  • "Save changes"
  • "Exit without save"
  • "Cancel"

In rare cases, more options than can be fit on the screen must be presented. In this case, a scrolling selection box may be offered instead. This is not glanceable, so should be avoided. "Cancel" may not seem the most clear label. It is instead a placeholder for the common term or symbol used in the OS to denote canceling or going back from the current action. In this case, the action is the presence of the Confirmation dialogue, so the application will be returned to.

When a choice is clearly the preferred one, or is the safest (e.g. preserves user data), that should be indicated. The OS standards should include a method of indicating button preference such as color, icon use or border treatment.

Antipatterns

Reduce clicks whenever possible. When a selection is made, it should immediately commit the change and proceed to the next step. Never force the user to make the choice, then press some sort of "Submit" button.

Do not over use the "single choice" variation. For example, if an application must quit and a Confirmation dialogue is useful, a dual choice would usually be better. Offer options to just quit or to quit and restart the same application immediately.

Carefully consider whether a Confirmation dialogue is the right pattern any time more than three choices are offered. It may be a natural part of the process. The use of the modal dialogue implies exceptional conditions or errors so should only be used when needed.

Unless the standard and exclusive way of canceling a process, do not provide a "Close" button for the Pop-Up dialogue. Even if the behavior can be mapped to both the "Close" and "Cancel" functions, the Confirmation dialogue presents options as a set of required choices. Closing the dialogue implies it is optional and can be avoided.

Do not develop new terminology, or use new or non-standard icons for simple behaviors like "Cancel" or "Back." Use the OS standard labels or iconic representations.


Next: Sign On


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.

Examples

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.

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