Introduce contextual view (drawer) to work items listing page
Problem
We conducted validation (https://gitlab.com/gitlab-org/gitlab/-/issues/40988) that helped us understand that individuals would prefer viewing the work item detail contextually within a drawer instead of a modal. This issue introduces the contextual (drawer) view on the work items listing page.
Proposal
Update the work items listing pages to open the item contextually within a drawer:
- Update OKR listing page to use the drawer. 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.
-
Update the Epics (as work items) listing page to use the drawer.
- This should be placed behind the work items feature flag currently in use for the new epics experience.
- This view will be used for all work items in the future but will be rolled out as a filtered experience for epics only. Once issues are on the new work items experience, we will combine this listing page and the drawer can be used for any work items displayed on the list.
👀 Additional details
The below additional context has been copied from this thread:
@gweaver: how big of a lift would it be to combine opening work items from the list and board in the contextual drawer with the opt-in to the work item detail view?
@ntepluhina: TL;DR: around 3-5 points to implement POC on boardsExplanation:
The issue list has the drawer already behind the
issues_list_drawerFF. It's not feature complete - we're missing at least design management and related merge requests, but the view is already there.It wouldn't be much more complicated to add the same drawer to boards and replace the board sidebar with it. The main complexity would be reflecting the updates from the drawer on the board card. Both board sidebar and board lists operate with the same type (
IssueorEpic). This allows Apollo Client to perform automatic updates on cards whenever we change issue properties in the sidebar. With the drawer, we will need to perform manual updates on the "active" board card since we will deal with different types. It's a temporary measure until we can fetch a list/board of work items, and mapping logic is rather cumbersome. Additionally, we would need to think about moving the card to a different list upon update (not sure it should be a part of the POC, we're not moving the cards now if I recall correctly).On top of that, I believe we need a few UX changes to the drawer (making it wider maybe with 2-column view) but I defer this to @nickleonard
I would be happy to implement the drawer on boards with the same FF so we could have better idea what's missing.
@kushalpandya: Just went through the discussion, I agree that having a shared drawer implementation as Natalia mentioned is the way forward here (with complexity to be solved for Boards, and perhaps Roadmap in future), but in any case, we can approach it for Epics list (i.e. Work Item list in future) with the following strategy;
- The current version of the drawer (with limited metadata visibility) is available for OKRs and is behind
issues_list_drawerFF.- We can update the Epics list implementation first to use the Work Items object structure such that this drawer component can be triggered from this list as long as same FF is true (and may be move this drawer behind
work_items_beta?).
- We don't need to implement this list from scratch as the current Work Items list can be re-used with some Epic-specific changes.
- Since the frontend component within the drawer will be shared, any new feature added here will propagate in all its usages without additional work.
@ntepluhina: this sounds like a great plan👍🏻 If we're able to move Epics list to use Work Items query, the complexity will be much lower comparing to the Issues list: we won't need any complicated manual cache updates like we're doing for issues