[🎨 Design] OKR: 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.
To address this pain point, we are exploring two potential solutions (at minimum) - a modal view and a drawer view. We will validate these approaches with users to identify the most effective and user-friendly approach.
User feedback
- Feedback from a large financial customer (linked issue) addressing the inefficiency of opening multiple tabs.
- User feedback on POC of drawer for OKR users
- Research effort that included evaluation of drawer vs modal
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.
- Research Issue
- Dovetail Insights
- Task completion & answers to questions (note: there are multiple sheets)
Proposal
Design Resources
Note: We want to maintain the animation of the drawer opening/closing (like in POC). The prototype doesn't include this simply due to a limitation in how it needed to be set up in Figma.
Based on the validated design direction, the following updates are proposed to the current POC drawer:
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
to24px
starting at a drawer width of768px
. -
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) - Some preferred options for this parameter are:
?view=<iid>
/?drawer=<iid>
/?preview=<iid>
- Whatever we use here should be consistent in all contextual view instances (from List, from Detail page, etc.). We currently append
?work_item_iid=<iid>
on the modal view on detail pages, which we would want updated to whatever is chosen here.
- Some preferred options for this parameter are:
-
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.
see sizing in Figma)
Drawer sizing (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
-
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.
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
🤔
- 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) - Note: this is looking to be addressed for the drawer component in gitlab-ui#1807
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.
-
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.-
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. -
Introduce the drawer view for OKRs hierarchy (child) widget
OKRs are already using the work item framework, and only allow children ofObjective
orKey result
. This means we can introduce the drawer for OKR detail pages without concern of some items not being able to leverage the drawer. -
[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). -
[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.
-
Update the current Tasks modal – Issues hierarchy (child) widget
-
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.-
[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. - [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.
-
[Requires Epics migration] Update the drawer on Epics boards
-
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.-
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. -
[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. -
[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.
-
Update OKRs to use the drawer for lists
-
[Requires Epics migration] Introduce to Roadmaps
Similar to list views, this functionality will be new.