Skip to content

[🎨 Design] Planning objects contextual view

Summary

The goal of this issue is to identify efficient ways for users to view the details of records within GitLab without the need to open multiple tabs. Currently, users face a cumbersome experience when dealing with multiple records simultaneously, which affects their productivity and overall satisfaction.

User feedback

Research

We conducted a solution validation study ( https://gitlab.com/gitlab-org/ux-research/-/issues/2807) based on the designs of the drawer explored in this issue. There were a couple changes that resulted from the 1st round of testing with users (see details in Dovetail), but overall the direction and design of the drawer tested well with users. You can find additional insights and considerations in the Dovetail link below.

Proposal

Design Resources

Based on the research and validation, we will be moving forward with the drawer view, which will include some modifications to the current POC.

Drawer design & content

  • Change the layout of the drawer to be based on how we are handling the responsive behaviors for the detail page (1 column vs 2 column, ancestors behavior, reflow of content, etc).
    • This may mean that we update the detail page behaviors to be based on the container size rather than the viewport (as described here)
  • Update the drawer header based on the attached designs
  • Change the drawer header to be fixed (not scroll with the content)
  • Ensure the attributes sidebar (when displayed as a sidebar at larger sizes) is sticky upon scrolling, similar to the detail page. (see example in prototype)
  • Increase the left/right padding of the drawer from 16px to 24px starting at a overall viewport size of 1200px (XL).
  • Add the ability to click on the entire row (outside of any links) of a list item to open the drawer.
    • Include a hover affordance of a background change ($gray-10) and ensure the pointer cursor is displayed.
  • Ensure we maintain the ability to open the full page in a separate tab when right clicking or command + click on the title (this works properly on POC).
  • Remove anchor quick links from content within the drawer, as we do not plan to support deep linking to items within an open drawer.
  • Clicking on any work item within a drawer (ex: a Linked item) navigates the user to the full page (does not update the drawer content). This is similar to how the POC currently functions.

When the drawer is open...

  • Append a string to the end of the URL that represents the drawer state and which item is open. This should also add the route to the browser history so that when using browser navigation (forward/back) it includes the parameter change. ( #367908 (closed))
    • Follow the same pattern that was updated for the modal in !162437 (merged) (#466257 (closed))
    • ?show=[GID] (Example: https://gitlab.com/gitlab-org/plan-stage/work-items-ga-epics/-/issues/2?show=152322607)
  • Ensure we maintain the ability to click on other items (now also including clicking the row on lists) to update the content in the drawer.
  • When clicking outside the drawer on anything other than another item in the list/board, close the drawer.
  • As discussed above, the browser Back button could also be used to close the drawer since we are adding a URL parameter
  • Ensure Esc remains as another option to close the drawer.

Drawer sizing (see sizing in Figma)

The current POC drawer uses a percentage based width. This proposal suggests moving towards set widths based on viewport breakpoints. This allows users the ability to resize their window to modify how much room the drawer takes up, rather than it always being a set percentage of their screen. In the future, we plan to introduce the ability to manually resize the drawer to help solve this problem.

  • On viewports < 992px (LG breakpoint) – display the drawer full width when open
  • On viewports = LG breakpoint (992px - 1199px) – display the drawer in SM width (480px)
  • On viewports = XL breakpoint (1200px) -> 1439px (custom) - display the drawer in MD width (768px)
  • On viewports of 1440px and up – display the drawer in LG width (912px)

Boards specific changes

  • Add a hover state to Board cards to match what we are doing on List items ($gray-10 background)
  • We will need to update the current pattern on boards to make clicking a title open the drawer instead of the full page. This will be a change for current users, but necessary in order to have consistency across the product.
  • When opening the drawer from a board, reduce the size of the board container (so users can still scroll through the lists), but do not reduce the filter bar area like it does today. See the video example below.
Board example board-view

Accessibility

  • The drawer should never be open while another drawer is open (close the existing drawer first)
    • As discussed below, I'm not sure if this behavior could be an added to the drawer component itself, rather than needing to be accounted for with each drawer implementation 🤔
  • When the drawer is opened, focus should move the the first element within the drawer.
  • When the drawer is open, focus should be contained to the drawer (otherwise keyboard users could focus things out of sight since the drawer overlaps content)

Rollout of drawer

This contextual view will be utilized in multiple areas across the product moving forward. Below are the initial thoughts on how we could best introduce the drawer to some of these areas. Based on engineering feedback, it may make sense to change this ordering.

  1. Update/Introduce the contextual view on on detail pages
    Instead of having different contextual views shown in the product, it makes sense to first update the current instances to the new pattern (Tasks), and then introduce it to other areas.
    1. Update the current Tasks modal – Issues hierarchy (child) widget
      Tasks currently use a modal for its contextual view, which we will be updating to this new pattern. Since Tasks are already work items, we can update this at any time.
    2. Introduce the drawer view for OKRs hierarchy (child) widget
      OKRs are already using the work item framework, and only allow children of Objective or Key result. This means we can introduce the drawer for OKR detail pages without concern of some items not being able to leverage the drawer.
    3. [Requires Epics + Issues migration] Introduce the drawer view for the Epic hierarchy (child) widget
      Before we can introduce the drawer view for items in the Epic Child items widget, we must ensure Issues can be opened in the drawer. Otherwise, some child items would open in the contextual view (Epics), while Issues would navigate to the full page (which would be a poor and inconsistent experience).
    4. [Requires Epics + Issues migration] Introduce the drawer view for the Linked widget – On all work item types (Epics, Issues, Tasks, OKRs)
      Similar to the point above, we need to ensure all linked item types can open in the drawer before enabling the drawer for the Linked widget.
  2. Update the current Boards drawer
    Boards already leverages a drawer for additional details when selecting an item. Instead of having two versions of a contextual drawer view of work items in the product, we should update this to match the new experience.
    1. [Requires Epics migration] Update the drawer on Epics boards
      We should update Epics boards first, as those will be migrated first to work items and can leverage the drawer without any issues.
    2. [Requires Issues migration] Update the drawer on Issue boards Since Issues cannot yet be viewed in the work item layout (without UX problems), this change cannot be made until Issues have been migrated.
  3. Introduce to List pages
    This functionality will be new to lists (outside of the internal POC). If we first rollout the changes to the current contextual views (Tasks & Boards), this will be a natural extension of this behavior for users.
    1. Update OKRs to use the drawer for lists
      OKRs are already using the work item framework. This means we can introduce the drawer for OKR lists without concern of some items not being able to leverage the drawer.
    2. [Requires Epics migration] Update the Epic list page to use the drawer
      Once Epics are migrated, we can update this listing to utilize the drawer.
    3. [Requires Issues migration] Update the Issues list page to use the drawer
      Once Issues are migrated, we can update this listing to utilize the drawer.
  4. [Requires Epics migration] Introduce to Roadmaps
    Similar to list views, this functionality will be new.
Edited by Nick Brandt