Marking this issue as blocked for the time being as we need to identify an approach. Also converted to story as it isn't a bug but a UX issue with the current implementation. More noticeable in the bugfest environment where there is more data and search is slow. Also linking to https://folio-org.atlassian.net/browse/UXPROD-2364#icft=UXPROD-2364 as it seems logical to consider this a search performance related issue for now.

hi @Ann-Marie Breaux
yep, I agree that this work is not for R1, and before we discuss approaches with stripes, it's better to involve (not only for wireframes) @Kimie Kester as she knows more about UX

Hi @Mikita Siadykh I talked with @Khalilah Gambrell about suggestions for changes to central components. Here's her recommendation:

@John Coburn says "Depending on how much work it is, they could submit a PR to stripes-components. Stripes-arch is pretty good. They may even come hang out in one of our stripes-arch meetings."

For something significant like changing the bahavior of the filter checkboxes, I think it would make sense to discuss any proposal in a Stripes-architecture meeting, plus make sure we have a solid wireframe from @Kimie Kester. Obviously none of this is work for next week, something to think about when the release work quiets down.

Hi @Mikita Siadykh That all sounds fine to me. It's a little odd, but I think users can live with it for now. There's a regular UI dev meeting, isn't there? I agree that it would be good to review the structure of the filters. With the date filters, we fill in the date, and then click Apply, so we already have a precedent for what you're proposing.

I'm going to leave this ticket open for @Dennis Bridges to review and make a final decision.

hi @Ann-Marie Breaux @Charlotte Whitt

looks like not a bug, it was done to avoid scenarios when user selects many filters in async way and receives last response from the BE and this response can be not not for selected filters, and as I know @Dennis Bridges is ok with it

example:

1. user selects filter1 - we make request1

2. user selects filter2 - we make request2

3. request2 is faster than request1

4. data for filter1 is displayed instead of data for filter1 + filter2

I'd like to propose better UX (as I think), that actually can be applied across application, implement "Apply filters" button - can be done for R2,  it's one more click for user, but in this case we don't make user to wait + we don't make too many requests to fetch data as user selects everything required and presses button. And it's better to involve other POs and UX designers (!important).