Filter panel opens when a chip is removed

ilayda21 commented 2 years ago

Description of the bug

When a chip is removed from the search and filter component, filter panel is displayed.

Steps to reproduce the behavior:

Go to https://canonical-web-and-design.github.io/react-components/?path=/story/search-and-filter--default-story
Add a filter.
Remove the chip.
Filter panel opens.

Expected behavior

After deleting a chip, filter panel shouldn't open.

ziheliu214 commented 2 years ago

This was designed on purpose to encourage people to select another filter. We don't have to fix this until any users raise the concern we (you guys 😼) will investigate it further.

reference: Google cloud console https://user-images.githubusercontent.com/61144986/137459444-5f9e2005-9dbd-42de-a819-fdd61ebc9d97.mov

marinacastejon commented 2 years ago

We discussed about it in the squad. While it might make sense in some cases to encourage people to select another filter, in many cases removing filter should just update the information displayed (in our case a graph) without re-opening the filter panel again. In e-commerce this is the standard. In the IBM Carbon design system they also follow that, see example. Therefore, we would like a version of this component that does not open the panel when removing the filter. @bartaz @ziheliu214

ziheliu214 commented 2 years ago

see example

The search and filter wasn't designed to be for e-commerce, its for dashboards with complex data records and multiple filtering categories, in which case users need to apply multiple filters at once (that's why we keep it easier/prominent for them to add another filter, and always being aware they can do both search and filtering).

In the example you gave, the filters are outside of the search bar - it's not our search and filter component where the filter chip can be entered in the search bar. This is more similar to the 'split search and filter' variant that we use on the website (e.g. charmhub where its similar to your e-commerce example).

clagom commented 2 years ago

@marinacastejon see what you all think about what Zihe pointed out, we discussed similar use cases for the split search and filter variant.

marinacastejon commented 2 years ago

Hi @ziheliu214 and @clagom , thanks for your explanations. I understand your point Zihe. I will express the need differently. In this case users need a component that enables them to:

Search for a specific item in a list either by browsing a list or by typing
Select this item
Filtering results based on their selection
Removing the filter easily without re-opening a panel (because it would be an extra un-necessary step for them)
The reasons why the split search and filter is far from optimal in this case:
- The search query is directly linked to the elements that appear as checkboxes, it does not makes a lot of sense the keep them visually separated
- Some users might have 50 items on the list, making it very inconvenient to have a collapsed list of checkboxes
- We want to minimise the space, since most users won't probably filter (hypothesis based on research), so having a filter list always visible on the left of the graph will take up more space than deserved.

Do we have such a component? If no, then I will propose a variant of the search and filter component in the WG unless you point me to a better solution.

ziheliu214 commented 2 years ago

@marinacastejon I see the use case of yours including the scope of 50 filtering items, I agree the search and filter component is good for this case.

However I don't see the point of closing the panel while the search bar container is on focus, reasons: 1) It doesn't hinder anyone to remove the applied filters, it opens simply for the reason to add another filter, referring the 4th point in your comment. 2) It's coded in the way that the container (which triggers panel open when on fucus) and input field (with blue outliner when on focus) are separate, and the default setting is without users trying to enter anything the panel is still open available for selection.

I think disabling the panel when the container is on focus, in general, will cause more usage damage compared to the current defect. Happy to discuss this in WG or DA .

hatched commented 2 years ago

I use the S&F component often and I can see a world where hitting only the "x" to remove an item would not open the drop down but any other focus action would. To be honest though this use case is quite rare for myself, I either want all the filters I've selected or none.

FWIW It's actually a bug that it's happening the way it is now, it's not being explicitly handled so maybe a happy accident depending on which side of the fence you sit on 😄

bartaz commented 2 years ago

It will be discussed in WG in canonical-web-and-design/vanilla-framework#4076

clagom commented 2 years ago

As discussed in here: https://app.zenhub.com/workspaces/-vanilla-squad-59438c953747487777fbe484/issues/canonical-web-and-design/vanilla-framework/4076

The current implementation of the component didn't take into consideration the UX specs: https://discourse.ubuntu.com/t/behaviour-delete-a-filter-chip/21546 In particular:
The input field should include chips (currently in a different container, separated from the input field)
With chips inside the input field element, the focus should wrap chips as well.
Users should be able to use backspace to remove chips (currently is not possible because of the separation of the elements). This is also an accessibility issue.
If the focus is on the input field, it should open the panel underneath
If there's no focus on the input field, the panel shouldn't open
Clicking with the cursor on the "X" to remove a chip from the input field shouldn't therefore trigger the panel to open

WG: please refer to the UX specifications in order to iterate on the implementation of the component. CC @bartaz @sowasred2012

anthonydillon commented 2 years ago

Clicking with the cursor on the "X" to remove a chip from the input field shouldn't therefore trigger the panel to open

I believe that is opposite to the UX spec:

ziheliu214 commented 2 years ago

Clicking with the cursor on the "X" to remove a chip from the input field shouldn't therefore trigger the panel to open

I believe that is opposite to the UX spec:

You are right, there should be a middle stage between the last 2 interaction stage - after removing the chip, the field remains inactive. Once on focus (with the blue outline) the panel is open.

clagom commented 2 years ago

Yes, what @ziheliu214 specified. Can you please update the specs to be clearer in that sense Zihe, thanks!

hatched commented 2 years ago

Users should be able to use backspace to remove chips (currently is not possible because of the separation of the elements). This is also an accessibility issue.

This isn't why it's not possible, you can't place or style elements inside an input element.

If we want to allow you to use the backspace button to delete the chips we need to listen for the backspace button when the input is focused, if the cursor location is at 0 and there are active chips then remove the last one in the list. This feature was just never implemented.

This will need some accessibility investigation as I'm not sure how that would "read" as the element would be removed from outside the input.

clagom commented 2 years ago

I understand it's not possible in the way it's been implemented, but it's definitely how this component should behave as an interaction pattern. It's a fairly common component and users expect the same behaviour and interaction. Now it looks like it but doesn't behave like one.

ziheliu214 commented 2 years ago

Yes, what @ziheliu214 specified. Can you please update the specs to be clearer in that sense Zihe, thanks!

cc @anthonydillon updated the behaviour discourse post: https://discourse.ubuntu.com/t/behaviour-delete-a-filter-chip/21546

github-actions[bot] commented 1 week ago

:tada: This issue has been resolved in version 1.2.3 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

canonical / react-components