Skip to content

Move client filter into filter card - #1888

Draft
timreichen wants to merge 1 commit into
jellyfin:masterfrom
timreichen:move-client-filter-into-filter-card
Draft

Move client filter into filter card#1888
timreichen wants to merge 1 commit into
jellyfin:masterfrom
timreichen:move-client-filter-into-filter-card

Conversation

@timreichen

Copy link
Copy Markdown
Contributor

Changes
This PR moves the all/recommended filter into the filter box.
This is in order to improve the readability of the page and in preparation for the redesign discussed #1878
This also goes hand in hand with #1886 where filters will always be visible.

Copyediting

To avoid "nitpicky" reviews, please ensure all of the following have been done for any non-trivial changes.

While you're waiting for someone to look at your pull request, How about looking at another one? You do not have to do this, but it will help ensure your PR is reviewed quickly in turn.

Issues

@jellyfin-bot

Copy link
Copy Markdown

Cloudflare Pages deployment

Latest commit 043b0176fb700cff0ceec74ee46517178aa4b5d0
Status ✅ Deployed!
Preview URL https://e300b708.jellyfin-org.pages.dev
Type 🔀 Preview

@BotBlake BotBlake left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not convinced by this change for a couple of reasons:

  1. We currently only show "Recommended" downloads by default. With this change, it's no longer obvious that a filter is active unless the user opens the filter menu.
  2. Switching between "All" and "Recommended" closes the filter menu automatically. None of the other filter options behave this way, which makes the interaction feel inconsistent.

Overall, I don't see a usability benefit here and would prefer to keep the current behavior.

More importantly, we already have an open issue discussing potential changes to this area. My understanding was that we were still evaluating and discussing possible approaches. Opening multiple implementation PRs before we've agreed on the desired UX creates additional review and maintenance overhead, especially if we end up deciding on a different direction.

I'd prefer that we first reach agreement in the issue and then move forward with implementation based on that consensus.

Kind regards

@timreichen
timreichen marked this pull request as draft June 2, 2026 12:00
@timreichen

Copy link
Copy Markdown
Contributor Author

I'm not convinced by this change for a couple of reasons:

  1. We currently only show "Recommended" downloads by default. With this change, it's no longer obvious that a filter is active unless the user opens the filter menu.
  2. Switching between "All" and "Recommended" closes the filter menu automatically. None of the other filter options behave this way, which makes the interaction feel inconsistent.

I agree, this Pr requires #1886 to always show filter options to be useful. Converted into a draft.

Overall, I don't see a usability benefit here and would prefer to keep the current behavior.

The benefit is that all filter options are in one place and not scattered over the page. This reduces cognitive load.

More importantly, we already have an open issue discussing potential changes to this area. My understanding was that we were still evaluating and discussing possible approaches. Opening multiple implementation PRs before we've agreed on the desired UX creates additional review and maintenance overhead, especially if we end up deciding on a different direction.

Maybe I misunderstood #1878 (comment), I interpreted it that the filter page would be independent from the redesign "download landing page".

I'd prefer that we first reach agreement in the issue and then move forward with implementation based on that consensus.

Kind regards

Sorry for the confusion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants