Back to Designs page

Table of Contents

Related Research

No research entries have been linked to this design.

Resources

Modals
Google doc

Entitlement modals
Google doc

Additional tags

No tags are assigned to this entry.

Modals

Design type: Modal | Product area: Hybrid Cloud Console
Bekah Stephens avatar

Author: Bekah Stephens
Last edit: April 16, 2023

Modal content (header vs. body)

DO

  • Keep the header brief/succinct
  • Use the body to explain the situation and highlight elements in more detail

DO NOT

  • Make the header too descriptive
  • Include changeable information in the header

Example

A user clicks on “Remove member” in a group’s page → Modal pops up asking them if they are sure if they want to remove the role.

The correct way to lay it out is to only specify specific member names and group names in the body of the modal, as opposed to in the header, because there is less space to adapt to changing names in the header.

 


Distinguishing item names

In modals where you are deleting, removing or editing an item, the standard is to bold these relevant item names to highlight/distinguish them. 


Do not put these items in quotations or italicize them as it will lead to inconsistencies in presentation.


Button placement

Buttons in classic modals should ALWAYS be left aligned against the outer edge of modals. The next button should then be 16px to the right of the first one. You can read more in the PatternFly Button guidelines.


Delete/Remove warning modals

When do I Delete vs Remove?

  • Use “Delete” when there is actual destruction of information.
    • E.g., Delete a group, Delete a system, Delete a role
  • Use “Remove” when the content/system is removed from a particular view but there is no destruction of information.
    • E.g., Remove from group, Remove from inventory, Remove user

 

Delete/Remove modal Design

  • Icon: These modals should have a warning icon placed to the left of the modal header. This can be seen in PatternFly guidelines.
  • Header should be succinct and ask the main question “Remove ___?” “Delete __?”
  • Body: Your body text will depend on your scenario, but use it as a chance to emphasize what will happen if the user continues and to convey more detailed information about what is being deleted (e.g. database name, group name, role name, baseline name….). Names (object names, usernames, etc.) should be bolded.
  • Button: To reduce ambiguity, it is suggested that you specify what is being deleted. In other words, the button should say “Delete ____” or “Remove ____”
    • From Abi: Because this is a cautionary, "Are you sure?!" dialog box, we don't want to leave any room for ambiguity.
    • In addition, the button in the modal should be red as it confirms a destructive action.
  • Keyboard focus: Keyboard focus should be on the first inter-actable element that is not a destructive one. E.g., if there is no data entry on a delete/remove modal it should keyboard focus to the “Cancel” button.

 

More information in PatternFly guidelines.

 

 

Deleting/Removing 1 item vs. multiple items
 

# of items deleted/removedHow to reference in the modalExample
OneList./mention that item’s name, in bold

Deleting one role in an RBAC group

Two or moreDo not list out the item names, just include the number of items being deleted in bold.

Deleting multiple roles in an RBAC group


Destructive actions (checkbox vs. no checkbox)

DO use a checkbox when:

  • The action will be hard to un-do
  • It is a destructive action that can not be un-done
  • The action could have a big impact elsewhere or on other parties

 

Example

A checkbox was used here because, although the user could recreate a group if necessary:

  1. This could take a lot of effort
  2. the action of deleting the group will impact a lot of users in the organization who may lose access to multiple pages they previously had access to.

DO NOT use a checkbox:

  • When the action is easily re-doable
  • When the action would not have great impact elsewhere or on other parties


Example

No checkbox was used here because a user could easily add a user right back into a group with minimal effort, and it would only impact that one user.


Action: Cancelling

What happens when a user cancels an action? (i.e., wizard, modal, general action)

** Yellow highlights indicate a guideline you MUST follow.

 

Should you show a cancellation modal?

It is not required that you show one. The decision is up to the designer’s discretion and you should base that decision on the circumstance. 

A few notes:

  • If it is a task they do often, don’t bother them with a confirmation.
  • Using these dialogs seems to be very personal; some users love them, some users hate them. 
  • What is required is to use a confirmation modal for a cancellation and NOT a toast.

 

When to show a cancellation modal | Things to consider

User scenario when they cancelGive them a confirmation model?
User has not entered any data when they cancelNo
Modal only has 5 fields or less to fill out, whether or not user has filled them inNo, unless the modal is complicated
User has only filled out 20% or less of a wizardNo
User has filled out more than 20% of wizardYes
User is cancelling an editing modal (i.e., modal for editing something that’s already been created)No

**Note that these are not hard guidelines. They are just possible suggestions to help you make a decision. At the end of the day, this is very context specific.

 

Here are some more detailed guidelines explaining the examples in this table.

  1. You could opt-to give the user a confirmation dialog depending on how much information they have inputted:
  • Example: let’s say you have a wizard with 40 fields. You could make it so that if they have only filled out 5 fields or less, they do not get a cancellation modal when they press cancel. On the other hand, if they have filled out more than 5 fields, they would get a cancellation modal.

2. You could opt-to not give the user a confirmation dialog at all if you think it would be very unnecessary.

  • Example: If a modal is only made up of 3 fields, it would not result in much loss to the user and therefore, it may be unnecessary to add the annoyance of having them confirm the cancellation.

3. If a user has not entered any data, do not give them a confirmation dialog since no data will be lost. 

4. Level of destructiveness will determine how severe the confirmation is. 

  • If the level of destruction is not great (this will be most cases, ie: they’re not losing something already created in the system) use a blue primary button.
  • If the level of destruction is quite great, and causes greater harm than the user having to re-input all the data, use a red destructive button.

     

Modal design

When a user cancels an action after having inputted information, they should get a confirmation modal that looks something like this:


Header: “Exit ___ creation?” OR something else if this doesn’t fit your use case for cancellation. Your header must be phrased as a question that will be answered by the button choices. It is important that you do not use words like “modal” or “wizard” as these may not be familiar terms to the user.

Icon: Add a warning icon to show more emphasis 

Body: “All inputs will be discarded.” Can edit this to fit your use case. The idea is to keep it straightforward.

Buttons: The button should answer the question posed in the header. The options should usually be “Exit”, or “Stay”, unless that does not fit your use case. 

  • The action that confirms following through should be the primary action:
    • Default to using a primary (blue) button here
      • Reasoning: The greatest consequence of cancelling the creation of something is probably the annoyance of the user having to recreate it from scratch. It will not be deleting something already created, and therefore should not cause a big impact.
    • However,  you can use a danger button if the action is truly detrimental
  • The actions that cancels the initial action should be a link button.

 

Why did we choose this approach?

After discussing this in the design share in March 2020, we posted a vote in our #mgmt-uxd slack channel. The public voted on the confirmation modal.
 

 

Examples of confirmation modal in use

Example 1 + flow (designed by Natalie Wong for Cost, 2/12/2020):

  1. User is setting up their cost model in a 5 step wizard
  2. They X out of it or click on the Cancel button before they are done completing it, which would mean losing all the already inputted data
  3. Wizard screen would get replaced by this modal (to avoid a modal on modal situation) that prompts the user to confirm that they actually want to quit out of the wizard and lose all their work
  4. “Yes, I want to exit” is the primary button because that is the action they wanted to take in the first place
  5. “No, I want to continue” is a link button because it is NOT the action they wanted to take in the first place, and would bring them back to the wizard, negating the initial action.

Example 2 + flow (Margot for RBAC, 3/2/2020):

  1. User is creating a group in User access and has inputted some data in the wizard flow
  2. User decides to either X out of the wizard, or cancel the wizard creation, which would mean losing all inputted data
  3. Wizard screen would get replaced by this modal (to avoid a modal on modal situation) that prompts the user to confirm that they actually want to quit out of the wizard and lose all their work
  4. “Yes, I want to exit” is the primary button because that is the action they wanted to take in the first place
  5. “No, I want to continue” is a link button because it is NOT the action they wanted to take in the first place, and would bring them back to the wizard, negating the initial action.

Slack conversation that inspired the modal design: