Modal

Modals are intended to be small, focused containers. They are used to display content that requires user attention without navigating away from the current page. Modals are typically used for tasks such as confirming actions, collecting user input, or displaying important information.

Keep in mind:

• Try to avoid placing large amounts of content inside a modal. For more complex or extensive information, consider using a full page instead. For example, if a modal contains a table with pagination, it likely requires more space than a modal can comfortably provide. This type of content is better suited to a dedicated page.

• Try to avoid scrolling within them whenever possible. While a modal can contain various types of content, it's best to keep it clean, concise, and easy to scan to prevent overwhelming users in a limited space.

Modal: Button hierarchy

Use as few buttons as possible, only include those that are necessary. Make sure button labels explicitly describe what will happen when the user clicks them. Button should be placed in the footer area of the modal. Gap between buttons should be 12px.

Left side

Maximum of two buttons:

• Delete actions: Basic (Alert). Usually for destructive actions like delete or remove.
• Other actions: Basic (Theme). Other actions such as download, edit, or upload.

The delete button should always be placed on the left side of other buttons.

Note: A delete button should normally require a confirmation step (for example, "Are you sure?") rather than performing the action immediately. However, if the modal's sole purpose is to confirm a delete action and the delete button is clearly styled as a primary/destructive action, an additional confirmation may not be necessary - in these cases the delete button should be placed on the right side as a primary button.

Right side

Maximum of two buttons:

• Primary button: Filled (Theme/Alert).
• Secondary button: Basic (Theme) or Flat (Neutral). Usally for canceling or closing the modal.

The primary action button should always be placed on the right side of other buttons. Primary button should be inactive until all required fields are filled out or necessary actions are taken.

Example: Modal with buttons

Here is an example of a modal with buttons and how they are placed:

Icon in buttons

Icons are not always necessary when text and color already communicate the action effectively. Use icons selectively, based on the context and user needs. When included thoughtfully, icons can enhance clarity and support accessibility. Cancel and close buttons typically do not require icons. For more information about buttons, see the Button documentation.

Here are some of the most common icons used in buttons within modals:

Name	Icon	Action
Trash		Delete/remove actions
Save		Save/Update actions
PaperPlane		Send request
Pen		Edit actions
Undo		Clear/Reset changes
ArrowUpToLine		Uploading image/files
ArrowDownToLine		Downloading image/files

To read more about Icons, see the Icon documentation.

Modal: Content

Modals can accommodate various types of content depending on the use case. Here are some common use cases:

Forms

Modals are often used to collect user input. This can include fields such as Inputs and TextArea. The modal might display a form that users fill out, and upon completion, they can either save the data or submit it for further processing.

Modals can also be used to present a list of options from which the user can select. This is often seen in cases like changing settings or selecting items from a list. Bifrost has components such as Select and Checkbox button that are good components for these use cases.

Action requiring confirmation

Modals are commonly used to confirm important actions, especially those that cannot be undone, such as deleting items or making irreversible changes. These modals usually ask for confirmation with buttons like Confirm or Delete. After the confirmation it should indicate that the action is done, either by: showing a loading state inside the button and the modals closes, or a text saying the action is completed.

Note: The button that triggers the "Action Requiring Confirmation" modal should not use the filled variant. The filled button variant should be reserved for the actual action performed within the modal. Buttons outside the modal should use the basic or flat button variants instead.

Information or feedback

Some modals are used to display information without requiring any user input. These might be triggered by clicking a button, and the information within the modal is often related to context or alerts the user to something important. It can also be used to indicate that an action is in progress, such as during loading or spinner states.

Modal: Interactive demo

Here is an interactive demo where you can explore different modal types and their behaviors:

Best practices

• You can place almost any type of content inside a modal, but always consider whether a modal is the best way to present that content.
• Width of the modal should be appropriate for the content it contains. Avoid making it too wide or too narrow. Within your service, ensure that modal widths are consistent to maintain a cohesive user experience.
• Always provide a clear way to close the modal, such as a close button or clicking outside the modal area.

Drawer

Drawers are ideal for displaying supplementary content without navigating away from the current page. They slide in from the side of the screen and can be dismissed easily. Drawers are used for tasks such as presenting additional options or settings, or displaying detailed information that complements the main content.

• In a drawer its more appropriate to have scrollable content compared to modals, since they often contain more extensive information, but try to keep the content concise and focused to avoid overwhelming users.
• A drawer comes with a fixed width (550px on desktop, full width on mobile). Ensure that the content fits well within this width.
• Same rules for the drawers that has position: bottom, but keep in mind that the height will vary based on content. Add scroll if the drawer gets too tall.

Drawer: Button hierarchy

The button hierarchy in drawers is similar to that of modals, with some differences in placement:

• Drawer buttons are positioned on opposite sides (e.g., primary action on the right, secondary on the left).
• Modal buttons are placed next to each other.

This applies when only two actions are present. When more than two actions are available (up to a maximum of four), place two buttons on each side. In this case, follow the same action hierarchy used for modals.

When more than two action are present, destructive action (such as Delete) should be placed on the left. If another button already occupies the left side, place the destructive action on the right side of the left group.

This hierarchy is less critical than in modals, as drawers are less intrusive and do not demand immediate user attention in the same way modals do.

Example: Drawer with buttons

This example shows a drawer with its buttons and their placement, as well as how a button behaves when you select Edit.

Drawer: Content

Drawers are versatile and can accommodate various types of content. Here are some common use cases:

Summaries

Use drawers to present summaries that give users quick context without pulling them away from their current task.

• Key details or metadata related to the main content.
• Overviews of related items added. Adding or removing items from the summary can be done directly within the drawer.

Filter

Drawers are a great choice for housing filters, especially when there are many options. Placing filters in a drawer helps keep the main interface clean and focused while still providing easy access when needed. This approach is particularly useful for:

• Category filters that would otherwise take up too much space on the main page.
• Advanced filtering options, such as those used in tables or data-heavy views.

Actions requiring confirmation

Drawers can include actions that require confirmation, such as deleting or resetting data. In these cases:

• The drawer initiates the action.
• A confirmation modal appears to confirm or cancel the action, on the left side of the drawer. This pattern ensures destructive or critical actions remain deliberate, while still benefiting from the non-intrusive nature of drawers.

Drawer: Example

Here is an example of a drawer used for summaries. Try to cancel to see an example of an action requiring confirmation:

How Drawers handle the chat bubble

When a drawer is open, chat bubbles will keep their position in the bottom right corner of the screen. This means that
drawer buttons will not overlap or cover the chat bubbles, but the chat bubble may overlap the drawer buttons instead. In this case, each service must adjust the drawer buttons' position further to the left. This design choice enhances usability by maintaining access to chat functionality even when a drawer is active.

If you have a chat bubble in your service, make sure to test how it interacts with the drawer and adjust the button placement accordingly. 1rem (16px) gap from the chat bubble to the drawer buttons is usually sufficient to prevent overlap and ensure both elements are easily accessible. Here is an example of a drawer with and without a chat bubble:

Best practices

• Use drawers for supplementary content that enhances the main interface without overwhelming it.
• Ensure that the content within the drawer is concise and relevant to the user's current context.
• Always provide a clear way to close the drawer, such as a close button or clicking outside the drawer area.