Bug fix: fix resetting search type when features are set

[ChunkyProgrammer]

Bug fix: fix resetting search type when features are set

Pull Request Type

• Bugfix

Related issue

#5125 (comment))

Description

Fixes some issues with unsetting values

Testing

• open search filters
• check a feature
• change search type to channel
• feature gets unselected
• check another feature
• type gets set back to all

Desktop

• OS: Linux Mint
• OS Version: 21.3
• FreeTube version: Latest nightly

[efb4f5ff-1298-471a-8973-3d47447115dc]

While testing this i was checking out which Feature selections are compatible with each other but now i understand that YT handles this different than the other current traditional filters (from the current filter selection only one can be selected per category). YT lets the user pick as much Features as they want if they return results

firefox_o7uVYL5MaI.mp4

We cant go this way for the Features filters because we dont apply the filter directly when it has been selected. The only thing we can do is checking which of the traditional filters are compatible with the Features.

• When Type Channels is selected all Features filters are incompatible (current behavior of PR)
• When Type Playlist is selected all Features filters are incompatible (current behavior of PR)
• When Type Movie is selected some Feature filters are incompatible, see screenshot below (isnt implemented in the PR yet)

Rant:
I now see that we make it super hard for the user to understand how our search filters work. If filters are not compatible with each other they just reset. The user has to keep guessing which one work with each other. YT does this way better, when the user selects a filter it greys out the filters that are not compatible with the active filter set. I think we need to do the same tbh. The current UI/UX is really bad.

[kommunarr]

I think we do have UX issues with ours for sure, but for the sake of discussion, it is worth pointing out that YT's has some issues we would not want to replicate.

• The one filter change and then auto-submit feature seems like a choice that's informed by their data of common usage, but to people who ever want to set more than one filter, it's very bad. If there's a way to set multiple at once with a keyboard or mouse shortcut, it's certainly not made obvious enough to the user.
• Their disabled styling is abhorrent; it's impossible for sighted users, let alone colorblind ones, to identify which options are actually disabled. The cursor is still pointer too, so it feels like there's not much feedback being provided on why a filter can't be set.
• I don't think the best user experience is necessarily just to make those options disabled if there's a conflict either. You could make an argument for the suggested visual change + the change being applied (as is the case today) + an "Undo last filter change" toast. Because technically, YT's solution is worse at both informing you of the root cause of the issue and letting you actually enable the thing you want to click on. It seems to be optimized for the use case of "You want to search [x] thing, and we want to prevent misclicks from removing what you set up," but as stated earlier, it makes sizable tradeoffs with other use cases to achieve that.

[efb4f5ff-1298-471a-8973-3d47447115dc]

I think we do have UX issues with ours for sure, but for the sake of discussion, it is worth pointing out that YT's has some issues we would not want to replicate.

* The one filter change and then auto-submit feature seems like a choice that's informed by their data of common usage, but to people who ever want to set more than one filter, it's very bad. If there's a way to set multiple at once with a keyboard or mouse shortcut, it's certainly not made obvious enough to the user.

Because of this i closed #1338 a while back

* Their disabled styling is abhorrent; it's impossible for sighted users, let alone colorblind ones, to identify which options are actually disabled. The cursor is still `pointer` too, so it feels like there's not much feedback being provided on why a filter can't be set.

I agree

* I don't think the best user experience is necessarily just to make those options disabled if there's a conflict either. You could make an argument for the suggested visual change + the change being applied (as is the case today) + an "Undo last filter change" toast. Because technically, YT's solution is worse at both informing you of the root cause of the issue and letting you actually enable the thing you want to click on. It seems to be optimized for the use case of "You want to search [x] thing, and we want to prevent misclicks from removing what you set up," but as stated earlier, it makes sizable tradeoffs with other use cases to achieve that.

I would love to see your enhancements in a PR ;)

[kommunarr]

Is anything requested for this specific fix PR? I didn't have any requests @efb4f5ff-1298-471a-8973-3d47447115dc

[efb4f5ff-1298-471a-8973-3d47447115dc]

When Type Movie is selected some Feature filters are incompatible, see screenshot below (isnt implemented in the PR yet)

Sorry for being unclear with my big wall of text. This needs to be added

[PikachuEXE]

Definitely need better UX but maybe another PR