Problem

A displayed element must be able to easily reveal a small or medium amount of additional information, while remaining associated with the current context or page.

A typical floating Pop-Up, with functions like buttons inside the window.

Solution

A Pop-Up is a child "page" smaller than the viewport, that appears on top of the parent page or display context which spawned it.

For mobile, these should almost always be "modal," with the Pop-Up having exclusive focus. Elements on the parent cannot be accessed without dismissing the Pop-Up.

The parent can be seen behind and around the Pop-Up, but should be clearly disabled.

Variations

A Pop-Up anchored to the bottom, with softkeys logically and visibly attached to it. Simple forms, such as sign-on, can reside in Pop-Ups. Pop-Ups may be free-floating, with space around all sides, or may be anchored to one side. Anchoring to the top is used when the Pop-Up is related to a condition in the Annunciator Row or another top-margin item, such as the URL strip of a browser. Anchoring to the bottom is most useful when on a device with Softkeys, or softkey-like on-screen buttons, which will be used in place of button actions within the Pop-Up itself.

Content may be anything, and is not a variation, just content.

If room allows, and there is value (viewing content on the parent, or providing access to other on-screen elements such as virtual keyboards), the Pop-Up may be moved around the screen.

For larger devices such as tablets, or in rare cases for handset-sized devices, non-modal Pop-Ups may be used. When this is chosen, a decision will have to be made whether the Pop-Up becomes obscured by the parent window (and if so, how to again grant focus to the Pop-Up) or whether it is always on top, and obscures a portion of the parent. These design considerations will not be discussed below, as they are currently such exceptions that there is no established best practice on how to achieve them.

Interaction Details

Only one Pop-Up should be open at a time. This is easily solved by simply not allowing access to the parent, but is a good principle to keep in mind.

Opening a Pop-Up is via almost any link, or as a result of other user or system actions. There is no special design method to launch a Pop-Up.

All Pop-Ups may be dismissed. Even for a step within a required process, the Pop-Up should be able to be dismissed, so the user may view their context, and take other actions that may only be allowed within the full page. Dismissal may be via a dedicated function like a "close" with icon in the corner, or as a part of the primary content, like a "Cancel" button adjacent to the submit functions.

A floating Pop-Up with associated softkeys. A scrolling list of selectable items or actions is within the Pop-Up. Actions the user must take within a Pop-Up should be considered "page level." Whether agreeing they have been presented information, confirming a condition or submitting form information, use buttons (or button analogues like softkeys) to commit the action. Buttons imply page submission or major action so the dismissal of the Pop-Up will be expected.

Avoid scrolling within Pop-Ups. Long text elements, such as legal agreements, should be in full pages, and not Pop-Ups. Selection lists within Pop-Ups may, however, scroll. They may work best with only portions of the Pop-Up scrolling, instead of the entire frame. This will allow the buttons to be revealed at all times, making the presence of actions clear, even if the actions are forbidden until scrolling has occurred.

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

Make sure the Pop-Up is clearly defined as not a portion of the page. Use OS-level framing, and other treatments to make it clear. Shadows are another valuable way to differentiate the Pop-Up.

Control items especially, including close buttons, and Softkeys should appear similar or identical to the OS standard controls. This way, users will not have to learn a new interface language.

Controls should also be as clear as possible, so cancel, accept and close buttons or functions are immediately obvious to the user, and require no interpretation.

The state change of not just loading the Pop-Up but obscuring the parent is also critical to communicating this. The parent should usually be overlaid with a white tint or black shade which allows viewing the content, but is enough different that it is clear the content and interactive elements are superseded by another.

Antipatterns

Do not let a Pop-Up spawn another Pop-Up Always consider ways to avoid using Pop-Ups. Generally, there are other solutions. Many mobile browser and OSs do not deal with Pop-Ups well, and may display them poorly, or confusingly.

For devices with Softkeys or softkey-like on-screen buttons, avoid use of buttons within the Pop-Up. Anchor to the bottom of the screen (or whichever side has the buttons) and use those instead.

Do not allow a Pop-Up to spawn (be the parent for) another Pop-Up.

Do not over-use Pop-Ups by including navigation, tabs and so on. Present the single information or interactive concept, then allow the Pop-Up to close when the user dismisses it, or the task is completed.

Examples