Modal guidelines
A modal says “pay attention to me and nothing else.”
A modal title should be one line
A modal title should be one line
The modal body will automatically scroll if the content gets too tall. Try to keep this from happening by keeping your content short and to the point.
The header sets the context
Short and sentence-case, the header should indicate what the modal is about.
The body is for a single task
This task should not require a lot of explanation or user interaction.
Buttons are right-aligned
The primary action is a filled button, and the secondary action is a link button. Labels should use strong action verbs.
Use a modal to silo a single action
A modal can gather input necessary for continuing the current workflow. This type of modal works best for a short, focused task. Use input modals sparingly—they interrupt the user's workflow.
Save dashboard
Do: A save action is a good use case for a modal. The meaning is clear and the content is simple.
Add a team member
Step 1 of 3: the basics
Don't: Modals aren't the best design solution for multiple steps or complex user input. An in-page form is more appropriate.
Open a modal on a user action
Let a user action, such as a button click, open a modal. Don't open a modal from a toolbar action—users don't expect it.
Avoid scrolling content
Modal content should fit in a single view. If your modal has a lot of detail or a long list of items, consider a different solution, such as a form or a table.
Don't stack modals
Opening a modal on top of a modal might mean your workflow is too complex. Instead, use a component that supports multiple steps, such as a form or steps.
Use a modal to ask users to confirm an action
The most common use of modals in the EUI Framework is to confirm a user action. This modal should start with a question, give users enough information to make a decision, and restate the action in the button label.
Save changes before leaving?
If you don't save, your changes will be lost.
Do: Use a modal for confirmation when the user might lose data. For the body text, use one to two short sentences that explain the consequences.
Great!
Your dashboard has been successfully created.
Don't: Confirmations aren't good for messages. Toasts are best for success messages because they are less disruptive. Error and warning messages often appear directly on the page.
State the action in both the header and button text
If the modal header is "Refresh this field?" then the button text should be "Refresh."
Refresh field list?
This action resets the popularity counter of each field.
Do: Use the same action verbs in the header and button text.
Are you sure you want to refresh this field list?
This action resets the popularity counter of each field.
Don't: Don't use a vague header such as "Are you sure?" or the button labels "Yes" and "No."
Create separate confirmations for single and bulk actions
It avoids the awkwardness of "Delete 1 pipeline(s)" and improves readability.'
Delete pipeline 'MyPipeline'?
You can't recover deleted data.
Do: Asking users to delete a single item should include the item name in the title, if possible. Use single quotes around the name if it helps clarify meaning.
Delete 6 pipelines?
You can't recover deleted data.
Do: For bulk actions, include the number of items in the title.
Sometimes a header and buttons are enough
You can omit the body if users understand the decision from the header and button text alone.
Remove index pattern?
Do: Here the header and body are enough. The modal asks the user whether to remove an index pattern — data won't be lost.
Remove index pattern?
This action removes your index pattern.
Don't: Don't write body text that simply repeats the title. It doesn't add value.