[EuiDataGrid] Cell filtering UX unusable after scroll

[timductive]

The new filtering UX on table cell hovers above the row. If the user scrolls then this badge can be hidden behind the table header and rendered unclickable.

Also, this UX seems to align left or right based on the datatype of the cell contents. It would be less confusing to always align to the right.

[cee-chen]

@MichaelMarcialis, mind chiming in on this? Particularly the left/right alignment

[cee-chen]

The new filtering UX on table cell hovers above the row

@timductive Can you clarify what's generating/rendering this filtering UX? Is it custom or is it something being rendered in EuiDataGrid?

If it's custom, you'll likely need to adjust the z-index on your side of things.

[timductive]

@cee-chen this is the default EuiDataGrid rendering UX for cell filters I believe

[cee-chen]

@timductive Oh wait sorry, I think I see my source of confusion. The first row's cell actions should overlap the sticky header:

But other rows don't, because the user can scroll to see the rest of the cell:

Are you saying you'd prefer all cell actions to always sit above the sticky table header? @MichaelMarcialis, any objection to that?

[timductive]

yeah maybe there's a way to calculate the z-index on scroll and if the cell actions are partially obscured then pull them forward. I know it is tricky because there is a point in the scroll where it no longer makes sense to have the actions floating above the header if the majority of the row is now obscured...

[cee-chen]

Right yeah, this doesn't look good for example:

yeah maybe there's a way to calculate the z-index on scroll

My question with almost anything data grid related: is this calculation/performance cost for potentially thousands of cells going to be worth it? Especially when the UX solution is for the user to scroll a bit more to see the actions?

[timductive]

it depends... what's the cost? it's one of those minor annoyances that takes away from the experience, but kibana has a bunch of these and in aggregate they feel unpolished. If the overhead to this calculation has an impact on performance then no, performance is more important.

[davismcphee]

The action floating over the header doesn't look great, but would there be a performance cost to having all rows use the same z-index that we're using for the first row, or is there something more to it?

To add some more context, we've had complaints that the new cell actions cause some UX issues in Discover (although they fixed some from the old design too). I think users are finding the new actions harder to use for a couple of reasons:

• While partially scrolled through a tall cell, clicking it focuses and scrolls to the top of the cell. This used to reveal the cell actions, but now they're obscured by the header. The solution is to scroll up a bit, but it's a minor inconvenience users can run into often.
• Since the old actions were located within the cell, it was easier to move the cursor from where you started hovering toward where the actions appear without them disappearing. Now the actions appear above the cell, making it easy to accidentally move the cursor outside of the cell trying to get to the actions, which hides them. You then need to hover the cell again, click to focus, or make sure to carefully move the cursor toward the actions while keeping it within the cell. Another relatively minor inconvenience, but running into it often can be frustrating.

[MichaelMarcialis]

Regarding the cell action menu on hover/select getting cut off in the overflow when a sticky header is in effect, I'd prefer not to simply change it so that the action menu continues to show, as this will look broken if/when users scroll so that the cell in question is partially or fully scrolled out of view (like in @cee-chen's example above).

I think a more elegant solution would be to have the position of the cell action menu dynamically change between top/bottom based on proximity to the edge of the scrolling container (similar to how our tooltips and popovers function when in close proximity to the viewport's edge). Whether or not such a thing is technically feasible, I will defer to @cee-chen and team, but I think this direction would yield a better user experience.

Also, when we were originally designing this change to the cell action menus, I had suggested positioning the menu at the bottom of the cells (rather than the current top positioning). This was changed to the top due to concerns of it getting cut off at the bottom. Perhaps if we implement dynamic positioning like this, we could also change the default position to the bottom until it is detected that it needs to be repositioned at the top of the cell.

Also, this UX seems to align left or right based on the datatype of the cell contents. It would be less confusing to always align to the right.

@timductive: Correct, the cell action menu is currently aligned to match the alignment of the cell contents (to avoid the actions potentially appearing far from the cell contents, in cases where the contents are small or the cell's width has been changed). Is the confusion you mentioned something that we've received user feedback on? I just want to make sure there is a documented a pattern of confusion before making any knee-jerk changes.

Since the old actions were located within the cell, it was easier to move the cursor from where you started hovering toward where the actions appear without them disappearing. Now the actions appear above the cell, making it easy to accidentally move the cursor outside of the cell trying to get to the actions, which hides them. You then need to hover the cell again, click to focus, or make sure to carefully move the cursor toward the actions while keeping it within the cell. Another relatively minor inconvenience, but running into it often can be frustrating.

@davismcphee: This is a fair point. By repositioning the action menu out of the data grid cells, it does potentially create difficulty in maneuvering the mouse cursor to the action buttons when hovering. This is a non-issue once a cell is selected however, as the action menu persists regardless at that point.

We have to remember that this change was made due to the fact that having the cell actions contained within the data grid cells was causing both the cell contents and the cell action menu to be obscured in some instances (ex. getting cut off at narrow column widths). During the redesign of the action menu, I decided that the lesser of two evils would be to not obscure the cell content or actions by moving the actions menu outside of the cell. Unless we see a pattern of user feedback indicating otherwise, I still feel that this is/was the lesser evil.

That said, perhaps there is something we can do to mitigate the increased difficulty with mouse cursor maneuvering on hover of a data grid cell. Would it be possible for us to slightly extend the hover zone around the action menu a bit to make it a bit less unforgiving when moving your mouse to the available actions?

[timductive]

@MichaelMarcialis I think the align left or right issue is related to the menu disappearing when you accidentally remove the hover. So if the mouse is always traversing diagonally, then you are more likely to trip the non-hover and lose the menu. Extending the hover area is one possible way to solve. I still think it is non-intuitive to have this menu now popping up in literally every possible corner of the cell if we proceed with dynamically choosing top and bottom as well.