UX for data grid cell actions

[ryankeairns]

As the use of data grid grows, we're encountering cases where teams desire to add multiple actions within a cell. I'm not certain this discussion will necessitate changes to the component itself, but some guidelines would be helpful, at a minimum, in order for us to maintain consistency with use of the data grid.

The current state

Currently, the data grid provides a hover action which allows a user to expand the cell contents and view more information. Discover uses this feature like so, accumulating three actions:

As further evidenced by this next screenshot (from this issue), the number of actions being added is reaching an untenable level from a UX standpoint. At a certain point, we begin to encounter overflow issues.

Relatedly, the RAC design team has been working through alternatives and generated several mockups to address the number of actions within the expand view. This has turned into the following near-term recommendation:

---

The path forward

For RAC, in 7.15 (8 days past FF at the time of this writing), they're having to make some quick hacks to alleviate the overflow issues by, likely, setting a default column width wide enough to show all the actions and to hide the overflow (this is already done).

Neither of these solutions strike me as long term or desirable UX approaches. At the same time, the product direction as conveyed by the engineers involved, is that these actions should not require multiple clicks (i.e. keep the 'add to timeline' action visible on hover).

To the point

What is the EUI and UX team stance on this?

• Should we provide data grid guidelines for this situation, explaining the intent of the expand action? (similar to table actions)
• Should we consider other design alternatives that either...
  • don't cover the hovered cell contents or
  • only show the expand icon below a certain column with (and always show all actions in the expanded popover?) or
  • something other?

[mdefazio]

I absolutely think we need a set of guidelines for the DataGrid (expand action and likely other aspects). It is a new component and so the learning curve can be a bit high for both design and engineer.

The original design issue includes a write-up specific to RAC in Observability and Security. But this should be improved for a broader set of rules: https://github.com/elastic/stack-design-team/issues/85. Including just for reference.

Some first thoughts on a guideline proposal:

Number of visible actions on cell hover

I would recommend no more than 3 cell actions visible on hover (including the expand action). This provides the option to have up to two actions and an expand action. The cell action icons should also be easily recognizable and clear which action will occur. For example: Filter In, Filter Out, Expand.

There should be an initial width set on the column if cell actions are enabled. The below shows image shows an 80px cell with 3 actions. I think it makes sense to still see at least one character of the cell's content when hover and displaying the cell actions.

Default layout for Expand Popover and Popover actions

Ideally, the exposed cell actions should go into the popover footer as shown already in the docs. If there are more that 2 actions, then a choice should be made to determine a primary action and then secondary actions should be treated separately. I don't think it's a hard requirement for the cell actions to stay in the footer. If the user is needing to perform other actions, then these should likely be exposed more prominently than the choices already presented to them.

Actions can potentially be placed to the right of the cell's full value (see original design issue for example). This is an attempt to mimic the placement of copy on a code block example.

Additionally, content can be placed between the cell value and popover footer. If providing a link, this should likely be reserved for changing pages or opening additional context. If adding content, be cautious that footer actions may be pushed down away from the original cursor position.

[ryankeairns]

This is great. Three seems reasonable as a recommended max, then show all actions in the popover including those shown in the cell. I wonder if we should go so far as to say if you're using the filter bar, in conjunction with the data grid, then filter in and filter out ought to be displayed... which essentially means all other actions go into the popover.

Tangentially related note about flyouts
What do you think about adding a section for the special 'open flyout' action? Use case being, I need to show much more detail than a popover can handle such as a full document view from the Discover table.

[mdefazio]

Adding from Caroline on Slack to make sure this gets noted:

I’d like to just make one suggestion. Please don’t rely solely on icons for any cell actions. That’s the reason why we implemented needing to fully label each cell action and then we force them to a full button with text in the popover.

[ryankeairns]

Another topic for the guidelines...

When to use cell actions versus row actions
Does this action pertain solely to the content of this cell, or does it apply to the entire row. If it's the latter, then it should very likely be its own 'Actions' column, for example.

This feels somewhat related to the note about when to open flyouts, as well.

[mdefazio]

Here is a worst case scenario for number of options needed. If some of these are not required for a column, they can simply be removed.

• Filter In
• Filter Out
• Copy
• Add to timeline
• Show Top Values
• View detail page/flyout of selected content

Mockup Option 1:

[ryankeairns]

Another note:
The guidelines would recommend showing filter in/out int he cell hover (if they're used). We note the possibility of using a custom action (e.g. Add to timeline) on cell hover but advise to do so sparingly when product requirements necessitate/demand it..

[mdefazio]

Mockup Option 2:
This shows the option to view the detail page as a click action on the cell value from the popover only.

[ryankeairns]

Just adding a note from our chat:
In the guidelines, let's describe when this might be worth considering and when to avoid. For example, use the link approach to navigate away; use an action (not a link) when you'll stay on this page.

[mdefazio]

Below are some general Kibana guidelines for the cell itself, and then also the popover based on the feedback from the larger team.

Cell Actions:

Cell Popover:

[ryankeairns]

Here is how I've been thinking about the actions:

1. The horizontal row = default actions and matches the cell actions
2. The vertical list = extra actions

Reasoning
I'm assuming the most common (or at least baseline) use case is data grid in conjunction with the KQL search bar on the same page. In other words, there seems a high likelihood you are using filter in/filter out. In that case, we are suggesting those be the cell (hover) actions. Then, whether you have short or long values in the cells, we would be defaulting to the most compact popover layout (i.e. a horizontal footer with no extra actions / no vertical list of actions below).

[cchaos]

I see this falling into a similar pattern that we already establish in EuiBasicTable actions and reinforce in the component itself, really without the ability to override unless you don't use the actions at all.

If there's a way to combine guidelines for both, or use the same pattern, I think this will help with user's expectation through consistency.

[adamwdraper]

cc @bfishel This might be something to consider for your audit of table actions.

[ryankeairns]

@cchaos so in the case where you are using filter in and filter out and have a preferred primary action like 'Add to Timeline', then the guidelines would suggest you use isPrimary for the Add to Timeline action only. Whereas, if you do not have a preferred primary action but you are using filter in and filter out, then both of those should be isPrimary.

Just for clarity's sake, we're also implying that we don't have an overflow menu in data grid, rather you have the expand action which encompasses the display of all actions for a given cell. Correct me, anybody, if this is wrong or unclear.

[cchaos]

Yes I'm bringing up the similarity between EuiDataGrid and EuiBasicTable in the sense that:

• EuiDataGrid cell actions = EuiBasicTable row actions
• EuiDataGrid expand button = EuiBasicTable overflow menu
• EuiDataGrid primary cell actions = EuiBasicTable Primary row actions

[cchaos]

Filter in/out

I'd like to take a moment to mention the repeated filter actions that we have in most DataGrid usages.

Applying two distinct filter buttons, one for in, one for out, within the cells themselves takes up a lot of room and adds a lot of noise for what I assume to be is a coupled action that can be simplified to a single experience.

What I mean is that the act of Filtering is a single action. It's whether they want to filter out or in that is the "choice". I would like to suggest a pattern/component that creates a unified experience around filtering at the data level. Primarily I mean, reducing the act to the primarily use "in" functionality, while prioritizing the "out" functionality.

I've POC'd a quick example of where I think we can optimize for "in" but still allow for quick "out" functionality, and then having both options be explicitly listed in the full format of the popover. The POC (I added to the Basic Table component because it was just easier) basically, creates a single "Filter" action that is shown on hover which when just cliked filters "In". But if the user ctrl clicks, will swap to an "out" function. Ten in the popover where we list ALL the options, the filter "in" and "out" are both explicitly listed.

Here's a screenrecording:

Screen.Recording.2021-09-01.at.01.59.42.PM.mp4

POC: #5124

[ryankeairns]

This is interesting. I also think it is separate from the guidelines in that the guidelines will reflect whatever is the current design whether that is two icons (now) or icon (in the future). That said, it does improve the situation. Should this become its own enhancement request then?

[cchaos]

They are tied together in the sense that if this is a pattern we agree is better than having to display both Filter action types as separate cell actions, then we'll need to plan this configuration into the component itself. Guidelines do not have to only address current functionality but can also suggest new functionality.

[mdefazio]

Here's an update on this:

Changes:

• I have added in some rationale based on @cchaos recommendation of the similarity of patterns with EuiBasicTable (thank you).
• Updated some of the guideline text and images per @snide 's comments
• Suggesting to remove the option of showing a cell action on hover, but showing popover as a single list (I believe this simplifies the implementation and our overall guideline)
• Suggesting to remove the option to style a single action differently than two actions. Not known to be necessary at this time.

I have created an issue (might need more clarity though) for EUI here: #5132

Will provide separate issues for Security and Observability showing their specific implementations.

[cchaos]

🙌 Love it! The simplicity of "Hey, you can only have up to 2 actions (other than the expand button) in the cell itself, the rest will just be a list in the popover" is exactly what we need. It's straight forward and can easily be incorporated directly into the component. I also wonder then, if the EuiDataGrid cell can automatically calculate a min-width based on the number of cell actions, to further avoid some of those sizing issues.

[cchaos]

I also definitely think we should add in this filter pattern into our docs examples.

[ryankeairns]

Awesome work @mdefazio !

[mdefazio]

Thanks for the quick feedback and direction from everyone—go team!

[chandlerprall]

This is great @mdefazio , thank you so much for putting all of this together! I've update the issue (#5132) with more specific implementation details.

[mdefazio]

@cchaos @snide @constancecchen @MikePaquette @mchopda @chandlerprall

Opening this back up to get a decision around how much do we enforce the 2 action limit on hover.

For most purposes, a 2 action limit likely makes sense and could probably remain as a guideline for this feature. However, Security has a use case (and current functionality) that providing 3 actions makes sense for them.

We had previously discussed an idea around providing 3 actions (filter in / filter out / timeline) but having the filter be a single icon with a keyboard modifier (pressing CTRL would filter out instead of the default filter in).

I think it makes sense to bake these guidelines into the component, but is it possible to have an 'easy' escape hatch? Much like EuiBasicTable, using the built-in actions cell adheres the UI to the guidelines. However, there is a custom action option here.

For quick ref, here are the EuiBasicTable guidelines regarding row actions which could help steer us in a direction.

[snide]

@MikePaquette, @adamwdraper and @andrew-goldstein can you verify the proposal I suggested works for the Security solution? We'd time that merge of #5675 to happen after 8.2 FF so that you don't need to worry about any immediate changes. That would give the team all of 8.3 to retrofit those changes into any overwrites you put together previously?

ccing @chandlerprall who I discussed this today with and OKed this from the EUI side. I'll put together a formal issue to capture the need.

@MikePaquette, assuming it's acceptable, can you vocalize it within the group so we're confident that's an acceptable plan?

[andrew-goldstein]

@MikePaquette, @adamwdraper and @andrew-goldstein can you verify the proposal I suggested works for the Security solution?

The Security Solution intentionally affords users a consistent set of actions anywhere on screen where a value is displayed, but abstractly, the primary actions are:

• Filtering
• Investigating (sometimes called "pivoting" in the domain of security products)

It's unfortunate that as noted in this discussion, there are two variants of the filtering case, Filter in and Filter out, however the existence of these variants doesn't diminish the importance of the investigation (pivoting) workflow.

@snide's proposal above to provide a reasonable default:

cellActionsVisible={2}

alongside documentation explaining why deviation from the default should be carefully considered, while still affording an override like:

cellActionsVisible={3}

feels like a reasonable solution that:

• Guides designers and developers towards the preferred path
• Enables solutions to, after careful consideration, still afford users access to the most important workflows with a single click

[MikePaquette]

Thanks @snide, If @andrew-goldstein 's assessment above is correct, then it LGTM!

[snide]

I'm closing this discussion. I've adjusted the issue and PR with the proposals. Thanks everyone.

[adamwdraper]

Thanks, @snide. Works for me as well.