Update the search results without manually clicking on the `Filter` button

[VWJF]

Simplified UI for Filters
I’d recommend removing the “Filter” and “Trash” buttons altogether and instead triggering filtering automatically when selecting or deselecting items from the dropdown menus.
Currently, the user must manually click the filter button to apply changes, but in my opinion, the interface would feel more intuitive and responsive if filtering occurred instantly as selections are made.

[VWJF]

@bpadovese The auto filter functionality is enabled in the latest commit and deployment.

TODOs for production functionality:

• Migrate the trash button functionality (to the functionality built into the bootstrap-select dropdown element) (deferred until after merging the latest changes to main branch)
• Remove Filter & Trash HTML buttons

[bpadovese]

That feels soooo much better. Thank you.

If it is not too hard, I’d suggest starting with a default filter selection (visually). For example, right now the main view begins with SRKW, J, and all pods selected, but the dropdowns show “nothing selected,”. It’s purely cosmetic, but having those default options pre-selected in the dropdowns would give clearer UI feedback.

To be clear, I’d suggest starting with something like this:

Instead of this (same functionality, just different visual feedback):

Also, one small UX tweak: it would be great if the dropdown menu didn’t immediately close after selecting an item. That way, users could quickly select/unselect multiple options without having to reopen it each time. The dropdown could still close when clicking outside it.

Or maybe... maybe a “Select All / Unselect All” option would help reduce the clicking:

Not sure which approach would feel better...

[VWJF]

• I have addressed the visual confusion (for the time being) by changing the default dropdown message. Preselected filters conflict/overlap with the concerns in Persistent Filter States in URLs Persistent Filter States in URLs #44. It's in the roadmap.
• The select all/ unselect feature is implemented, but it causes other UI components to break. So I will postpone it to a later/independent issue.

Currently, with the dropdown updating results without clicking the filter button, you will notice that as soon as you click on a choice, it changes the results, and the dropdown closes. If you have to make another choice, you have to go back and open the dropdown, and it will automatically close again on the next selection. Effectively making the dropdown a single choice at a time.

Try the following 2 scenarios:

1. NRKW Clan R Pod R1 (the only pod in clan R). If you click any unrelated pods (A, B, C, D, H), those combinations don't exist; the results don't change, and the dropdown remains open. The moment you click on pod R1, the drop-down closes.
2. NRKW Clan A, Pods A,B,C,D,H,I1/I2/I18 (pod R1 is not part of clan A). If you click on any pod not part of clan A (I11, I31, G1, R1), the results don't change, and the dropdown doesn't close. When you click on a pod that is part of clan A, you have to open the dropdown multiple times to select each pod (which is a frustrating ui experience in a different way).

This behaviour is due to the tightly coupled implementation, which I can only decouple by tightly coupling somewhere else.

Is the current dropdown behaviour intuitive enough? Is it just me who finds that it remains non-intuitive?

Once you have had a chance to experiment with the current dropdown behaviour, I will push a fix that doesn't auto close the dropdown.

[bpadovese]

Im not sure I am getting the same behaviour as you are describing, at least on chrome.

For instance in scenario 2, If I select clan A and Pod R1, you are right, the results don`t change, and the dropdown doesn't close. If I then select a pod that is part of clan A... the dropdown still doesnt close and I can continue to maek any selection I want.
So it seems consistent to me.

Or did this last commit change that? But I like the current implementation. It does require the user to manually close the dropdown. but I think this is preferable than having to open it multiple times every single time they want to change the selection.

---

I undestand that it is a limitation of the implementation taht we cant filter the dropdowns themselves when selecting a clan for isnstance? Say, we select clan A and the dropdown for the pods dont display clan R1 since it is not in clan A. Is it the frontend library that you are using that doesnt allow this?

[VWJF]

Yes, the last commit changed it. I forgot that the catalogue automatically rebuilds and deploys itself (every day at around midnight – I thought the automatic build was disabled and I would have to manually trigger an update). But it seems like you understood the original scenario, and the latest implementation is preferable.

---

There isn't any frontend library/framework in the catalogue viewer. The vanilla JavaScript is constrained by the restrictions/assumptions in the initial prototype, combined with the accumulation of technical debt. The underlying data structure is a list of all options for dropdown 1, a list of all options for dropdown 2, and so on. The relationship across options is not maintained.