Global actions

Use global actions when there’s a single set of actions, or bulk actions, to be taken against any or all resources in a given view or page.

Published: February 10, 2023

On this page

Key UX concepts

Global actions are performed on one or multiple resources. For example, upon selection of an item in a table, at page level in a detail view page, or the selection of multiple resources, such as upon bulk selection of several items in a table.

Page header with actions

Page title

Card header with actions

Cards title (1/2)

Table header with actions

Table title (1/2)

Variable name
Text value
Type
Description
Item 1
First
1A
This is the first item
Item 2
Second
1B
This is the second item

Global action locations

Place global actions in the action stripe of the header component at the top of the page, or as part of the table or cards header. Add actions as buttons or button dropdowns if users can perform actions on the underlying content.

Order of actions

The order of buttons is important when action is required on a data set. It follows the order of major resource management actions.

  • Place buttons in this order: View details, Edit, Delete, Create [resourcename]

  • Add other action buttons between the Edit and Delete buttons.

  • Add other Create buttons between the primary Create button and the Delete button.

  • Place status actions at the far left in the action stripe.

    • For example: Deactivate, Activate, Status 3, View details, Edit, Delete, Create [resourcename]

Number of actions

  • For less than five actions, use individual buttons.

  • For more than five actions, use a button dropdown to collapse non-primary actions.

On mobile viewports with more than one non-primary action, consider moving these actions into a button dropdown to conserve space. Follow the guidelines for responsive design.

Sticky header - optional

If users need to take an action on resources upon selection, consider using a sticky header in your table or card collection to house your global actions.

Disabled reasons in button dropdown - optional

For extra clarity, provide a tooltip with inactive actions that explains why the action is unavailable. These tooltip explanations should be as short as possible, with longer descriptions belong outside the dropdown component.

This feature should be used scarcely because it adds additional information to the interface. Use the tooltip only if the reason an action is inactive is unclear, and there are no other suitable approaches to guide users.

General guidelines

Do

  • Use only one primary button per page. Primary buttons are like The Highlander , there can be only one.
  • Actions that do not relate to one resource should be placed in the page header, or as part of the table  or cards  header. For example: A primary action in the table header to create a new resource.
  • Use buttons for actions.
  • Use a button dropdown to present 5-15 contextual actions that users can choose from to initiate one action.

Writing guidelines

General writing guidelines

  • Use sentence case, but continue to capitalize proper nouns and brand names correctly in context.

  • Use end punctuation, except in headers and buttons. Don’t use exclamation points.

  • Use present-tense verbs and active voice.

  • Don't use please, thank you, ellipsis (...), ampersand (&), e.g., i.e., or etc. in writing.

  • Avoid directional language.

    • For example: use previous not above, use following not below.

  • Use device-independent language.

    • For example: use choose or select not click.

Component-specific guidelines

Button

  • For labels of button dropdown, indicate the purpose of the actions set.

  • Use an action verb.

    • For example:

      • Rerun

      • Edit

      • Delete

  • Don’t use terminal punctuation (period, exclamation point, question mark, colon) in button labels.

  • Follow the writing guidelines for button.

Accessibility guidelines

General accessibility guidelines

  • Follow the guidelines on alternative text and Accessible Rich Internet Applications (ARIA) regions for each component.

  • Make sure to define ARIA labels aligned with the language context of your application.

  • Don't add unnecessary markup for roles and landmarks. Follow the guidelines for each component.

  • Provide keyboard functionality to all available content in a logical and predictable order. The flow of information should make sense.

Component-specific guidelines

Alternative text

  • Provide alternative text with the ariaLabel property if there is no button text or if you are conveying additional information through means other than text.

    • For example, buttons without text, buttons with meaningful icons, or buttons conveying additional information with color.

Keyboard interaction

  • By default, the tab key focuses the component.

  • The enter key performs the action.

Actions

Ways to invoke actions in the interface.

In-context actions

Use in-context actions when there are actions tied to a singular element, resource or container.