Description

Contextual toolbars appear next to an object or selection and focuses on the content-level actions that are available for that item at that given moment in time. Not all actions need to be in a contextual toolbar, as the Application toolbar should carry the complete list of possible actions for that app.

Usage

Use contextual toolbars as a direct and timely shortcut to content-level actions that are housed in application toolbar. If a component has space for its own native controls, such as its own toolbar, buttons, and overflow or contextual menus, then prioritize using these controls for content-level actions before considering contextual toolbars at all.

• You want to offer a content-level shortcut to actions in the Application toolbar
• You need an option that provides more than one action
• Your content-level actions can be placed directly in the component itself
• Your contextual toolbar provides only one action by design
• You intend to use more than 8 actions. Rely on the application toolbar and use a contextual menu instead
• Your interactions for clicking and selecting already trigger another menu, Action sheet, or other content-level action component.
• You are dealing with page or workflow-level actions. Use the application and footertoolbars instead

Anatomy

Contextual toolbars are made up of a series of buttons on a floating bar. Its four main parts include:

• Container, required; white background container with rounded corners and a drop shadow for a floating look and feel. The container may be oriented in a horizontal or vertical style.
• Buttons, required; icon-only, standard buttons in transparent style. Toggle, menu, segmented, and semantic buttons, as well as text-buttons in all varieties, should not be used at all.
• Bottom triangle, optional; used instead of menu buttons to suggest additional options are available. When a button with a bottom triangle is clicked, it opens an Action sheet. See Behaviors & interactions for more info.
• Dividers, optional; separates actions from each other or group them together.

Behaviors & Interactions

Access

Contextual toolbars appear when a selection is made and disappear when nothing is selected. Decide on the orientation of the toolbar, either vertical or horizontal, based on how close it needs to appear to the content while being mindful of the information it may cover. For example:

• Selecting a table’s whole column may trigger a vertical toolbar but selecting an individual cell triggers a horizontal one instead.

The vertical style is found () to the right side of the selection, and the horizontal style () above or below it. Don't place contextual toolbars on the left side of the selection.

Multiple Options

Bottom triangles act as affordance when multiple options exist under one button. Clicking on a button with this triangle opens an action sheet with all related contextual actions. Because action sheets contain no groupings or nesting, do not use them for showing submenus. If submenus are needed, forgo contextual toolbars altogether and use contextual menus instead.

Contextual Behavior

Contextual toolbars have two styles of offering contextuality:

• A standard set of actions that will always be relevant (such as delete)
• A dynamically changing set of actions relevant at different stages or conditions.

Regardless of whether the actions are standard or dynamic, they must always be useful in order for the toolbar to maintain its relevance, and not just clutter the UI. The cost of covering up the UI for irrelevant actions is too great to pay for users who would rather just see more of their content.

This contextual behavior includes scenarios where multiple items can be grouped in one selection. To ensure Contextual toolbars remain useful in those scenarios, ensure the actions contained in it apply to the entire group.

Best Practices

Design for speed and relevance

Contextual toolbars are used specifically for their ability to give users what they need, in the moment they are most needed, in order to speed up the user’s flow. If the actions they offer are not relevant at the moment they appear, then the toolbar itself becomes bothersome.

That means contextual toolbars should not offer all the actions that can be done to a selection, but rather, only the ones that are relevant to that moment in time.

To avoid the frustration that comes from the unpredictability of a dynamically changing toolbar, ensure a complete list of these actions is also offered in the menu bar of the application toolbar – either spread within different menus, or all in the same app-specific custom menu. In that sense, contextual toolbars become a shortcut to those actions in a hyper-focused and contextualized way.

Contextual toolbar displaying a focused set of actions contextual to the selection. A complete set of actions are placed in different menus across the application toolbar.

Work with content-level actions

Not all actions are appropriate for a content-level component like a contextual toolbar, even when they will affect the selection. Some appropriate examples include:

• Adding, editing, or deleting the selection
• Showing and hiding component-specific properties
• Controlling the data on display, such as sort, filter, and ranking
• Formatting text, images, links, and other data-specific settings
• Pinning, commenting, sharing, and other generic actions
• Grouping, ordering, arranging and other relational commands
• Accessing tools, settings, and configurations specifically for the selection
• Applying styling or other conventions such as calculations, transformations, or formulas to the selection
• Inspecting details specifically about the selection

Not too few, not too many

How many is ‘too many’ actions in a contextual toolbar? How few are ‘too few’? The optimum number lies somewhere between 2 to 8.

In an event, either by its dynamic nature or by design, where a contextual toolbar will be populated with more or less actions than the 2-to-8 range, consider the effect this will have on the user experience and plan for an alternative. For example:

• Fewer than 2 actions: Contextual toolbars with fewer than two actions are bothersome and add little value to the user experience. It would be far more useful to access those actions directly in the selected component itself, rather than looking for a contextual toolbar to access them.
• More than 8 actions: A toolbar with more than 8 actions increases the cognitive toll of users every time they need to parse through all icons to identify the one they need. In addition, the larger the toolbar becomes, the more information it covers beneath it, and also the further away some buttons will be from their content. At that point, contextual toolbars become more of a burden than a helpful tool.

Don't let them get covered

Be careful not to let contextual toolbars get covered, either fully or in part, under any circumstances. In certain scenarios, if the regular placement of the toolbar means it will be obscured for whatever reason, consider making minor adjustments to allow it to appear in full. For example, when selecting an item...

• ...in a crowded area: let the toolbar appear on top of other objects in the UI.
• ...close to the edge of the screen: shift the location of the toolbar slightly so it doesn't run off completely.
• ...next to a side panel: auto–scroll the browser window so the toolbar doesn't appear beneath the panel.

Specifications

Links & Resources

• Fiori Guidelines: Action Sheet
• Core Visual Design Specs: Action Sheet (Fiori3)
• DemoKit Sample: Action Sheet
• API Reference: sap.m.ActionSheet

Support

If you have any questions or feedback about this page, please contact our team. For further information and questions in regards to the Design System, please visit the DNA Design SharePoint.