Clarity datagrid detail pane expected interaction and responsiveness

sarahxy commented 1 year ago

Authors: hsarah@vmware.com Reviewers: darinas@vmware.com, lwinona@vmware.com Approvers: TBD but probably the same ^ and maybe some staff designers and UI eng

Summary

The details panel pattern is dependent on the height of the datagrid container. Because of this, detail panels can be extremely short and extremely long, hurting the user experience.

If datagrid is set to show numerous items per page:

Screen jumps to the top of the panel if a user is scrolled further down in a datagrid, so that user loses reference to selected item
Large empty space in taller datagrids
Requires scrolling to close the panel for longer content

Additionally:

What is default behavior of short datagrid with detail pane? Should the datagrid have a set height regardless of number of items, or should height be proportional to number of items? For latter, what happens when detail pane expands?
Not practical for use cases with a short datagrid and long detail panel content... For the implementation side, how does scrolling within the detail pane interact with scrolling in the datagrid interact with the full page's scrolling?)
Component itself is "buggy". Edges are not aligned with the grid (might be fixed)

Key terms and concepts

Detail pane: https://clarity.design/documentation/datagrid/detail-pane

Motivation

The detail pane is being used in many designs (e.g., in VMC) as a way to show additional details about a datagrid item that might not make sense to capture on the datagrid column itself. As a result, questions have arisen from eng teams on how a user should interact with this component, and with other components in the same context with the detail pane is open.

Goals

(Build) An experience where when users see items on a datagrid and open the item for more data shown in the datagrid detail pane, they do not lose context of the selected item when the detail pane opens, and are able to still scan/scroll through the datagrid (independently of the detail pane).
(Provide) Documentation with default datagrid state with few items, intended detail pane interaction with a datagrid showing fewer and also more items, and guidance on when to use the detail pane (as opposed to modal or full page).
(Deliver) Updated, accessible, and responsive detail pane UI component in datagrid, with updated documentation on guidelines.
(Define) Interaction of component with the datagrid, and ideally also with the context of the page it sits (e.g., scrolling and responsiveness) and any defaults.

Future Goals · (Build) a unicorn if I had infinite time

Non-Goals This item is not in scope of this proposal

Personas and user stories

(This should actually apply for any persona because this is more an expected interaction, so just provided some examples.)

Personas ANY

User Stories e.g.,

As a VI admin, I want to open the view detail pane of a specific VM (after scanning the datagrid of all VMs in my environment), in order to reference specific information on a specific VM. --> important to keep reference to VM
As a VI admin, I want to be able to quickly scan through my list of VMs and quickly open any VM's details, in order to quickly monitor or troubleshoot VMs. --> basically the expected detail pane interaction to open details on VM with as few clicks as possible (don't have to close and open, close and open)

Proposal

Proposed behavior with notes.

(Needs definition) Default size / height of datagrid with few items. (Is height relative to number of rows, or fixed?)
If datagrid is showing less items (e.g., less than X), then when the detail pane is opened, the default detail pane height should be X OR match the datagrid height and be neatly aligned with the datagrid boundaries.
If datagrid is showing more items per page (e.g., greater than X), then when the detail pane is opened, the detail pane height should be relative to page height (aka not exceed visible screen real estate), and independently scroll from datagrid — only exception is once the user scrolls the page past the datagrid, the detail pane should then align to the datagrid (aka it should not "float" on a page above or below or outside the bounds of datagrid). --> The reason for this is because when a user SELECTS a datagrid item, the detail pane should open without the user losing context of the item they selected to open. (Currently it jumps to top.)
(Needs definition) Scrolling and responsiveness of detail pane when it has more content, in context of datagrid's scrolling and height, in context of greater page (which may contain headers, dashboard overviews and actions above datagrid, multiple navigational elements like side nav and top nav)

Suggestions:

The product vROps has a solution for their in-house built datagrid detail pane. Basically fixes height of datagrid when detail pane expanded relative to height of browser window. (See daily builds and play around with "Alerts" datagrid.)

Research

N/A

Related Materials

Winona's UI component log of issues found, specifically 1.1.4. (This issue was raised previously by Winona and Janet to Steve.)
Written summary of issue + Winona's temporary solution in this Slack message, but the temporary solution was not implemented by eng.

FYI @pdaigle @lerch015

Jinnie commented 1 year ago

Some historical context (2017) from the old repo: https://github.com/vmware/clarity/issues/552

It was actually one of my first requests to Clarity, I wasn't part of the team yet. I personally agree that it can be disconnected from the Datagrid layout. I even consider that it can be an entirely separate component - a non-modal dialog, stackable to the sides of the viewport, possibly manually resizable, so the user can choose how much of the underlying datagrid remains visible.

lerch015 commented 1 year ago

@Jinnie A blade/docked panel component could be an option, but it would need to be fairly configurable, and getting it to appear, and appear correctly, would be largely on the team doing the implementation. We'd also need to rationalize it with some of the other modal elements we have (mostly dialogs and modal windows); eg. why use one in one context vs. the other?

Generally speaking, I'm not a huge fan of components that impose modes that exist outside of the component's container as part of their base functionality because it tends to take some autonomy away from the designer leveraging those components. For example, what if they had a breakout bar on the right hand side of the page with the table? Would that now need to be done some other way? Add a lot of stuff like that up and design teams end up with a lot fewer options available to them to solve for their users needs.

vmware-clarity / ng-clarity