[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.

[MichaelMarcialis]

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.

@timductive: Yeah, that's a fair point. Having both the horizontal and vertical positioning be dynamic in concert may indeed be too much. If we settled on a static horizontal position, but kept the vertical positioning dynamic (assuming it's technically possible), do you feel that would that be a reasonable compromise? Or would you prefer neither vertical or horizontal be dynamically positioned?

[JasonStoltz]

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'm wondering out loud if it's possible to put a slight delay on this. Even just a few hundred milliseconds or something.

[JasonStoltz]

Alright, we had a lengthy discussion around this as a team today. Recapping here:

Here are the issues as we understand them, just to recap:

1. The actions menu can appear left aligned or right aligned, depending on cell contents This can be confusing

2. When scrolling, a user can lose sight of the actions menu when it scrolls behind the header cells On it's own, I don't perceive this as a big issue. I believe most users would simply scroll the actions back into view just like any other content that gets scrolled out of view. However, it's made worse by number 3 below.

3. When a user clicks on a cell and it snaps into focus, the actions menu is not visible Because it focuses as top-aligned, the user never sees the actions menu and is unaware that it is scrolled out of view.

4. When hovering (not when focused), hovering to the actions causes the actions menu to disappear This can be a frustrating experience, but I'd imagine quite minor. I wonder how many users actually encounter this?

Here is our proposal

Solution for 1: We will turn off the dynamic horizontal alignment.

Solution for 4: We will add a slightly larger hover zone for the actions menu. We'll add X (to be determined based on what works best) number of pixels to the side of the actions menu to increase the hover zone and account for hover that just narrowly miss the target.

• We considered adding a slight delay to hover off, but the delay makes the experience seem laggy
• We considered making the expanding the size of the hover zone for actions to be the entire width of the cell, but this would make the cell above it unclickable for compact one line grid rows.

Solution for 2 and 3 We will not do anything, for now. We will explore adding an intersection observer, but we're concerned about performance here. We can't gauruntee we can implement this, but we can do at least a quick spike. With an intersection observer, the actions menu would drop to the bottom of the cell when it is scroll to or past the header row.

• We considered placing the actions menu below the cell, but we'll encounter the same issues with the bottom of the table as we do currently with the top
• We considered increasing the z-index of the actions menu, but the UX is not great. You can currently see it in the top-most cell of the data grid:

[timductive]

thanks for the analysis @JasonStoltz I think this is a reasonable plan