Explore improving the discoverability of filtering in tree views

[miguelsolorio]

Refs #140601

During the last iteration we explore how we could improve the discoverability of filtering in tree views, so this issue aims to bring the discussion around the specific design interaction. Currently you have to place your focus in a tree view and then start typing. In this exploration, we'll propose to surface an entry point in the view toolbar via a dedicated action. We could alternatively add this to an ellipsis menu to reduce the visual clutter. Lastly, we'll look at simplifying the filtering options and only filter the results (as opposed to highlighting the matches).

CleanShot.2022-04-05.at.01.21.51.mp4

@joaomoreno would love feedback here on the proposal and any additional options we can explore.

Related Issue

• "Normal" filtering input for trees #70646
• Usability "souce control" tree element filtering bad #140563

[joaomoreno]

Coincidence: #146821

I really like the ideas in the sketched video. I think code structure-wise it will be hard to implement this in a single place and just have all trees benefit from it. But we can certainly add these actions across all views we find crucial to have it. Also the empty state would be new and we'd have to figure out how to also benefit from it with the usual type to filter experience... maybe typing would trigger the widget and erasing what you've typed would show the empty state instead of hiding it, as it's done today?

Unsure if it's clear given your description, but we do have a setting to change from highlighting to filtering workbench.list.keyboardNavigation... maybe you meant changing its default?

[miguelsolorio]

the empty state would be new and we'd have to figure out how to also benefit from it with the usual type to filter experience...

yea we'd need to find a good default (i.e. min-width) for this state since this is triggered by an action and not by text, happy to play around with this

maybe typing would trigger the widget and erasing what you've typed would show the empty state instead of hiding it

the tricky part here is that the x almost always closes something instead of clearing, so we could use a different icon if we wanted to clear things. was trying to mirror closer to the find widget.

Unsure if it's clear given your description, but we do have a setting to change from highlighting to filtering workbench.list.keyboardNavigation... maybe you meant changing its default?

I'd love to know more about the use case where you'd want to only highlight vs filter because most filters will exclude the non-matches so the current behavior is a bit confusing in that respect. I was proposing to simplify the UX a bit but happy to discuss if we have a solid case for highlighting.

[joaomoreno]

I'd love to know more about the use case where you'd want to only highlight vs filter because most filters will exclude the non-matches so the current behavior is a bit confusing in that respect.

The decision here was made based on the default expectation towards pressing a key on a list, speaking in broader terms of software. Usually, focus navigates to the next element which matches what the user has typed (think Finder, Windows Explorer). Code does that and goes beyond: it hightlights all other possible matches and narrows keyboard navigation to that subset only. We posited that making it filter by default would just annoy users who are used to that usual navigation pattern of type A to go to next element which contains A.

[miguelsolorio]

I do wonder how many people navigate the tree with the typical "type A" pattern as I've used those patterns before in lists, but they tend to be more ephemeral and not stick around. In the current feature, if you type to navigate and then continue clicking to your target, the filter stays visible which is different from other patterns. Would love to experiment to see if there is a way to balance between the two. I think a more natural progression is to still navigate on keypress but don't use the filter UI (which more closely mirrors Finder/Windows Explorer). We could even introduce a setting that changes the "mode" that a user might want if they liked the previous experience:

CleanShot.2022-04-21.at.15.31.45.mp4

And below are a few other ideas for filtering that iterate on some of the feedback:

Option A

This one closely mirrors what we already have except it shows a cursor to indicate the focus of input and has an icon as the entry point.

CleanShot.2022-04-21.at.14.55.50.mp4

Option B

This one explores if we had a "mode" where it strictly filters the results (what I would expect to be the default behavior).

CleanShot.2022-04-21.at.14.56.28.mp4