Allow users to filter in table column headers by changing OuiBasicTable

[KrooshalUX]

Is your feature request related to a problem?

The established pattern for filtering table data does not meet modern use cases of filtering table values in a clean and practical way. Currently,OuiFilterGroup is used next to a search bar (if present) above a table - for each filterable column a button is added to the OuiFilterGroup. This increases visual noise, and visual noise increases cognitive processing, increasing friction when interacting with an already data-dense experience. Example taken from Reporting .

While this use case is limited to two filterable columns, but imagine if all columns were filterable, and what that interface may appear as.

What solution would you like?

Make filters available in table column headers within OuiBasicTable

A user clicks the filter icon (OuiIcon type="filter") in a given column, and can, onHover, include (OuiIcon: type="check") or exclude (OuiIcon: type="cross") selects one or more dynamically populated filters (Either utilizing OuiFilterSelectItem if it can be used independently of OuiFilterGroup, or a new composed component which combines OuiPopOver + OuiSelectable + OuiSearchBar). Selections are applied onClick.

If needed, a loading indicator would appear while the filter is applied (this may be a different experience between OuiBasicTable and OuiInMemoryTable).

Filter icon changes state to filled to communicate there is a filter applied. Selected values are pinned to top of OuiSelectable when OuiPopOver is opened to reduce friction in deselecting a selected value. Additionally, a column-specific Reset and global table Reset functions are available. Note: this might require an additional glyph be added to OUI Icons to represent the active filter (OuiIcon type="filterFilled")

Additional open question: Would it be useful to users to see a values count?

What alternatives have you considered?

Modifying OuiFilterGroup and nesting filters by column. Concerned that this is too high friction for filtering a table.

[kgcreative]

Thanks @KrooshalUX for exploring this. A few open questions that I think warrant additional exploration:

1. Reset filters button: This feels like a lot of wasted space, perhaps we can explore a smaller text link to gain a bit more vertical space
2. Do we need a different treatment for searchable vs filterable?
   1. For example, I can see a use case where we might want multi-select of something that only has a known number of options (e.g. status, which might have active, creating, deleting, processing, etc)
   2. Alternative, you have columns like name or title, where you might want to search for a value, rather than filtering because each item is unique, and you might not want to do auto-sorting or typeahead for searching values
3. How might we indicate sortable, vs filterable, vs searchable? That's potentially a lot of overhead in the titles
4. How might we account for tables that query an API, vs in-memory tables where all the values have been loaded into memory? (And would we need to / want to?

[KrooshalUX]

@kgcreative all great questions!

1. I accidentally provided sample designs that had the search bar layer "off" - I have updated the issue with the corrected screens. The reset button is intended to be to the right of the table search bar, where OuiFilterGroup would typically be.

2. Great question - it has been my understanding that the search bar above the table indicated that all values in the table would be searchable. Are there cases in which this is not accurate? I may need additional context on points i and ii to fully develop an opinion on function/visual treatment.

3. We may need to re-evaluate the overall look & feel of table headers to address spacing and visual importance (more like the OuiDataGrid component, perhaps. Here is what sort + filter would look like if we kept sort the same as it is implemented today (the up/down arrow indicates what columns are sortable, what their current sort is and follows the column title vs having an absolute alignment):
   

4. My only thought so far is that we may need a loading indicator for API querying, and that loading behaviors may differ between the two table types - but I am not sure if that addresses use cases / potential performance issues you may have been thinking of. Are you able to expand on this question?

[kgcreative]

1. Noted! This makes a lot more sense
2. Often time we refer to the specific column in the search placeholder text to help disambiguate this. (e.g. Search Name, Country or Search Description, etc)
   1. With OuiInMemoryTable, we can make more field searchable, but there are cases where if the search bar initiates a backend query, we might only search over a specific column.

[seanneumann]

@KrooshalUX I love the thoughtful dive into this! Thanks for driving this!

[KrooshalUX]

@BSFishy Can you take a look at this proposal and provide any thoughts or concerns? We are hoping to get this into OUI Component Refresh roadmap soon.

[BSFishy]

Nothing is sticking out to me, looks like a solid proposal 👍

[BSFishy]

@KrooshalUX Could you make a new consolidated issue with specific action items for implementation of this?

[KrooshalUX]

@BSFishy the next step would be for engineering to take a pass at a meta issue with the implementation details based on the UX delivery. This will help us find any potential gaps in the UX designs and I can provide additional information when needed. Since this is our first time iterating on a component in this way, I am looking to this as a learning opportunity for all of us. Feel free to ask more questions here or in the engineering meta issue.

[AbhishekReddy1127]

@BSFishy @KrooshalUX @kgcreative
I'm left with few questions.

1. By adding the column filter option, it does impact the current sorting behavior of the column. Right now the sorting happens when we click on the table header cell including the name, white space and sort icon. By implementing the filter option/icon, we need to restrict the sorting only on the sort icon right?

2. When does the global filter show up? Does it have to be there always or it has to be conditional? The reason why I am asking is because it would occupy a significant amount of space on the screen.

3. For the reset button, instead of showing it disabled, does it makes intuitive to show that button only when the user applies filters?

4. In mobile view, where should the filter options show up?

[kgcreative]

1. Sorting should be restricted to the name, or sort icon. Filtering will be only filter icon. We can remove the header as a tap target.
2. what do you mean by the global filter? I think this replaces that with column filters. Global filters would be for the dashboard level, and not really part of basic table. We would have a reset filters button adjacent to search, but that's it. I imagine that if you were to add filters via the search, then those would apply to the corresponding columns?
3. I think we're still forming opinions on this. I do like showing "reset filters" only when filters are applied.
4. We might need to think about the mobile view further. When I see it in the documentation site, i think we need to think about whether we show is as a drop down similar to "sorting", or if we do it in-line in each of the cards. This might need a bit more investigation. cc: @KrooshalUX

[KrooshalUX]

These are all great questions, thanks for taking a look into the proposal to help us identify gaps @AbhishekReddy1127

Building on / responding to @kgcreative response:

1. It shouldn't impact the sort, no - for example if column a was sorted a>z and then i filtered column b to only show x values, the sort in column a would still be true.
   1a. For the interaction, however, I am looking into a hybrid button approach for sort and filter, however I am hesitant to remove the one-click-to-sort function that is currently present, its pretty nice.
2. Correct this meant to replace most, if not all, implementations of using OuiFilterGroup or the OuiSearchBar filters that re commonly added by builders above the table (which is the scale problem we are having with new projects that require more columns than the filter bar can really handle). There are some edge cases here recently brought up in AI/ML that we need to take a deeper look into, so I will need some time on that from a pattern perspective, but that does not impact the implementation of these in-column filters.
3. Possibly - at the time of publishing this proposal, we were still discussing the disabled pattern button. Since a lot of builders want to use / are utilizing incremental search, I am hoping for a one-button solution to clear filters and searches. I think we could probably get away with utilizing the same pattern they have here for sorting, but I will need to take a deeper look. We haven't studied much on mobile usage yet.

I'll need some additional time on the shifts needed for the proposal to be rounded out. I will follow up here when I have some more concrete thoughts around these items.