Modals
Design type: Modal | Product area: Hybrid Cloud Console
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
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/removed | How to reference in the modal | Example |
One | List./mention that item’s name, in bold | Deleting one role in an RBAC group |
Two or more | Do 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
A checkbox was used here because, although the user could recreate a group if necessary:
- This could take a lot of effort
- 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
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 cancel | Give them a confirmation model? |
User has not entered any data when they cancel | No |
Modal only has 5 fields or less to fill out, whether or not user has filled them in | No, unless the modal is complicated |
User has only filled out 20% or less of a wizard | No |
User has filled out more than 20% of wizard | Yes |
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.
- 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
- Default to using a primary (blue) button here
- 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):
- User is setting up their cost model in a 5 step wizard
- 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
- 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
- “Yes, I want to exit” is the primary button because that is the action they wanted to take in the first place
- “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):
- User is creating a group in User access and has inputted some data in the wizard flow
- User decides to either X out of the wizard, or cancel the wizard creation, which would mean losing all inputted data
- 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
- “Yes, I want to exit” is the primary button because that is the action they wanted to take in the first place
- “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.