You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the issue tracker for open and closed issues that are similar to the feature request I want to file, without success.
I have searched the documentation for information that matches the description of the feature request I want to file, without success.
This issue contains only one feature request.
Problem Description
We currently allow filtering search results by matching substring on some routes (i.e., Subscribed Channels page, Remote Playlists, History, User Playlists, Channel page) but not on others (i.e., Subscriptions, search results, Watch page). The latter is because these results are not fully loaded in, and we want to make it clear that we're only showing the loaded-in results. Still, this can be irksome if you want to search for something on those pages.
Proposed Solution
Implement a control that's present on the routes that don't currently results (i.e., all of the ones stated above) that allows you to filter visible results through a search. Ideally in a way that can be invoked and seen at any scroll level down the page. It has to very clearly communicate that it's only showing the currently loaded-in results. I'm still unclear on how this should work with a lazy list of videos like the Subscriptions page.
Alternatives Considered
Watch route is optional given there are so few recommended videos anyway.
Choosing this PR is a step away from a generalized "Find in Page" search, which I'm starting to think will be pretty unnecessary once we have more specific search bars on about every route.
Issue Labels
ease of use improvement
Additional Information
Cho
The text was updated successfully, but these errors were encountered:
jasonhenriquez
changed the title
[Feature Request]: Search for results in routes that don't support it
[Feature Request]: Search for results in routes that don't currently support it
May 4, 2024
Just to be clear the pages that have search bars, are the ones that are actually properly searchable.
The ones that don't have them are the ones where we would only be able to search stuff that is currently on-screen, but from various issues here on this tracker and in the general chat, the people that are asking to be able to search on those pages, want to be able to search through not loaded content too (like searching through the entire comment section on a video, which would require making thousands of requests to download all the comments first).
So if anything like a "search stuff currently on-screen" is implemented, it should be clearly separated from the search bars that are able to do proper searches. I don't like the idea of trying to place them all in the same place, when they serve completely different purposes.
Guidelines
Problem Description
We currently allow filtering search results by matching substring on some routes (i.e., Subscribed Channels page, Remote Playlists, History, User Playlists, Channel page) but not on others (i.e., Subscriptions, search results, Watch page). The latter is because these results are not fully loaded in, and we want to make it clear that we're only showing the loaded-in results. Still, this can be irksome if you want to search for something on those pages.
Proposed Solution
Implement a control that's present on the routes that don't currently results (i.e., all of the ones stated above) that allows you to filter visible results through a search. Ideally in a way that can be invoked and seen at any scroll level down the page. It has to very clearly communicate that it's only showing the currently loaded-in results. I'm still unclear on how this should work with a lazy list of videos like the Subscriptions page.
Alternatives Considered
Watch route is optional given there are so few recommended videos anyway.
Choosing this PR is a step away from a generalized "Find in Page" search, which I'm starting to think will be pretty unnecessary once we have more specific search bars on about every route.
Issue Labels
ease of use improvement
Additional Information
Cho
The text was updated successfully, but these errors were encountered: