Define design for drawer component
Problem
Today, we rely on modals to reveal critical information, show information without losing context, or when the system requires a user response. Unfortunately, modals have their downside, including; overlaying the experience removing most of the page from the user's view, multiple interactions are limited and difficult to solve for, and content size and breadth is limited.
Solution
Utilize a side drawer flyout (where appropriate) to reveal critical information, show information without losing context, or when the system requires a user response.
Example
GitLab boards
Side-drawer | Gif |
---|---|
Proposed Tasks
This issue
-
Define Anatomy of a drawer -
Define drawer guidelines (content alignment, empty state, headers, actions, sections) -
Define expanable sections
-
-
Create Sketch visuals with drawer variations -
Define interactions
-
-
Validate and define Accessibility best practices -
Create component page in design system -
Add rules/usage and design pattern to the new drawer page in the design system
Anatomy
Layout | Measures |
---|---|
- Use 16px right & left padding to give the content more room to breathe
- Use 24px vertical padding for the title to give it better visual separation and more room to breathe.
Usage
Dos and dont's
|
|
---|---|
Use to display additional or supplemental information to the user about an element or item. | Use for critical interactions, such as confirming a deletion event. |
Use for complex creation, edit, or management experiences. | Use when to display large tables, data sets or metrics that are better suited to a larger view. |
Trigger the drawer after a user has taken action on an item. | Surprise the user by opening a drawer unexpectedly. |
Include one focusable element within the drawer. | Close the drawer unless the user has taken action to do so. |
Layout content based on the pajamas layout and spacing guidelines. | |
Use an icon as the primary trigger when an element or item's main action is different than opening a drawer. | |
Include a descriptive hover state when using an icon to trigger drawer interaction. |
Example use cases:
- Show more information about an issue without taking the user to a new page
- Show more information about a feature without taking the user to the documentation
- Show more information about a vulnerability instead of using a modal
Other possible uses cases:
- Changing the setting of a feature
- Changing the configuration of a feature
- Adding / Removing / Adjusting permissions of a member
- Setting a users status
- Editing an issue's information
- Editing an epic's information
Sections:
There are two main sections of a drawer.
- Header
- Content
Header:
- The title is set in
ui/02/h2-4base
with 24px spacing above and below. - Actions are left-aligned and below the title.
- The close icon is always present and right-aligned in the header.
- The title should truncate after 3 lines to avoid pushing content too far down in the drawer.
Actions:
No actions | Multiple actions |
---|---|
Content:
Content selection should be based on the experience you intend to promote. Content should be structured according to our layout and content guidelines.
Content sections (Post initial component design)
There are two main options for content sections within the drawer.
Static sections | Expandable sections |
---|---|
Additionally, there is the flexibility of not including a section header in static sections.
Static section w/header | Static section w/o a header |
---|---|
Choosing a section type is dependent on a few factors but should be considered on a case-by-case basis.
- The amount of content you wish to display. The more content you intend to have the more you should consider using the expandable section.
- The number of sections you wish to display. The more sections you intend to have, the more you should consider using the expandable section.
Expandable sections:
Expandable sections have 2 states, expanded and collapsed. These states are reinforced through the use of a chevron icon.
- If you are using an expandable section then you must use a section header since it gives context to the user about what is within the section.
Expanded | Collapsed |
---|---|
Placement:
By default, drawers should always be pinned to the top-right and bottom the window directly below the global navigation. Drawers should extend the entire height of the browser, much like the issue sidebar does toady.
Interaction:
The drawer will appear following the motion guidelines
-
200ms with an ease-in animation.
-
By default, everything is overflowed by the drawer unless you designate a component not to be.
-
IF full-width elements exist, define their behavior as required by the experience you are designing.
Open/Close:
Opening:
-
Like modals, drawers should never take the user by surprise when they open. Don’t surprise users by opening a drawer. Let a user’s action, such as using a button, following a link or selecting an option, trigger the drawer.
-
By default, items that require a drawer should use the icon.
-
When there are multiple actions associated with an item, use the icon paired with an actions dropdown. The action dropdown should contain an option to open the drawer. This action can be called "More information" or another appropriate title depending on the experience you are intending to create.
Closing:
-
There is one primary way to close the modal, by using the close button/icon in the actions section. All drawers should have this action available to users.
-
The second way to close the modal is by using the
esc
key. This is mainly to help with accessibility.
Scrolling:
The drawer is designed to allow for scrolling content. When scrolling begins, the drawer content scrolls below the header.
States:
Loading:
The drawer should utilize the skeleton loading pattern when possible.
Empty:
IF an empty state is required, please follow the empty-state guidelines while being mindful of illustration size.
Small screens and mobile:
The drawer maintains the same behavior all the way down to the small breakpoint, at which point it begins taking up 100% of the viewport width.
Accessibility:
- Drawer states (expanded/collapsed) should be announced by screen reader (SR).
- Focus moves within the drawer when expanded.
- Intentional keyboard trap keeps tab order (looped) within the drawer until it is collapsed. This is so a user cannot focus on anything hidden under the drawer.
-
esc
key should collapse the drawer along with the close button.
Related patterns
Links / references
Pattern checklist
Make sure these are completed before closing the issue, with a link to the relevant commit, if applicable.
-
Read our contribution guidelines, especially the For GitLabbers section. -
Create a Sketch file in your progress folder just for this pattern and make sure that: -
You have not created a duplicate of an existing pattern, symbol, layer style, or text style. -
You have used the proper method for creating the pattern depending on the complexity. Atoms and molecules are symbols, organisms are groups. -
Typography uses text styles. When applicable, colors use shared styles.
-
-
Ask a UXer to review your Sketch file, linking them to your latest commit so they know where to find it. If they have the capacity, they should assign themselves to this issue. -
QA of your Sketch file by the reviewer. -
Add your changes to the pattern library. When copying things over, watch out for duplicated symbols, layer styles, and text styles. Some of our recommended plugins can help you find and remove duplicates. -
QA of pattern library by the reviewer. -
Create an issue in the Design System to add the pattern documentation. Mark it as related to this issue. -
Add an agenda item to the next UX weekly call to inform everyone (if it's a new pattern, not yet used in the application).