Update SearchFiltersPanel for Coach

[nucleogenesis]

Summary

• Updates SearchFiltersPanel to accommodate latest design changes which will be used in the quiz resource selection
• Adds a button to Quiz Resource selection where you can view the accordion-ized versions of the filters
• Only focuses on updating the appearance and minimal functionality - so the filters, when clicked, will be applied as expected, but they will not create search chips (however, Move useChannels & SearchChips to kolibri-common #12745 will make this possible upon further development)

Follow-up tasks (which I can do here and/or make an issue for):

• Add category icons to KDS per Figma - should be aligned to the keys used in the code if possible (ie, if the key used in Kolibri were the label for the icon that'd be helpful)
• The ActivityButtonsGroup component could use an update that lets use modify how they flow on the screen. We could fit 3, maybe 4 per row in the side panel but they display only in two columns. Perhaps some flex styles could do us well here to serve all use cases

References

Closes #12521

Reviewer guidance

Feature QA

• Go to Quiz creation and click the "Search" button there
• See that the filters align to the design changes (FIGMA)

NOTE: This is largely design focused, so any functionality issues will be addressed when it is fully integrated into Coach

Regression testing

• Search and filters should work exactly as before all throughout Learn (ie, no accordions, just the same as it has been)

a11y guidance, keyboard nav in particular

I have added tabindex=-1 to the KIconButton for the chevron to the right on the accordion heading area, so you will go from one accordion to the next

• See that your focus is trapped in the side panel modal
• See that focus works as expected when using the "Categories" buttons in particular because they open a KModal, which should also trap focus before taking it back to where it was before
• Opening/closing accordion sections works, aria-expanded should be set as expected
• Should be able to close the side panel w/ keyboard nav

[github-actions]

Build Artifacts

Asset type	Download link
PEX file	kolibri-0.18.0.dev0_git.20241114210926.pex
Windows Installer (EXE)	kolibri-0.18.0.dev0+git.20241114210926-windows-setup-unsigned.exe
Debian Package	kolibri_0.18.0.dev0+git.20241114210926-0ubuntu1_all.deb
Mac Installer (DMG)	kolibri-0.18.0.dev0+git.20241114210926.dmg
Android Package (APK)	kolibri-0.18.0.dev0+git.20241114210926-0.1.4-debug.apk
TAR file	kolibri-0.18.0.dev0+git.20241114210926.tar.gz
WHL file	kolibri-0.18.0.dev0+git.20241114210926-py2.py3-none-any.whl

[radinamatic]

Unfortunately, the search sidebar comes up empty for me on both Firefox and Chrome in Windows 10 😕
(there are channels with exercise resources on the device)

Firefox	Chrome

db-logs.zip

[marcellamaki]

@radinamatic only on windows 10?

[radinamatic]

Apologies, this looked to me like something that would not be influenced by the OS type, so did not think to check yesterday...

Just confirmed that I can equally replicate in Firefox and Chrome on Ubuntu 20.04:

Firefox	Chrome
	https://github.com/user-attachments/assets/767cef54-9ebe-4ace-9800-96d4303a0bd0

[nucleogenesis]

I've run into a couple issues getting a few things exactly to spec which I will detail here.

There are a few places that we should probably consider refactoring sooner than later I think -- namely:

1. Uses of SearchFilterPanel in Learn - There is a bit of a balancing act between the two depending on whether windowIsLarge or not. SearchFilterPanel will render a SidePanelModal when !windowIsLarge which makes SearchFiltersPanel a little wonky to "drop-in" somewhere. Then in the TopicsPage, the side panel has to live in a particular fixed position when windowIsLarge.

I think that this can be done w/ a little bit of reworking to how SearchFiltersPanel renders itself and updating TopicPage and LibraryPage to handle the responsibility of things like how/where it is shown depending on the window size. I started down the path of trying this while working on this PR and it's going to be a little bit fiddly to get going.

2. SectionSidePanel - This was created as a wrapper for "when the side panel is open" during Quiz creation, but it ultimately required some overly specific handling of "when can the user go back or not":

kolibri/kolibri/plugins/coach/assets/src/views/plan/CreateExamPage/SectionSidePanel.vue

Lines 57 to 69 in 4bda163

	watch(route, (newRoute, oldRoute) => {
	// Here we basically handle all of the edge cases around when we do and don't show the back
	// button in the heading of the side panel -- basically, we're going for:
	// - If we just loaded, no back arrow (ie, refresh the page w/ the panel open)
	// - If we're viewing bookmarks or have gone into a topic show the back arrow
	// - If we're still not on the same route as before, then show it
	canGoBack.value =
	oldRoute.name !== PageNames.EXAM_CREATION_ROOT && // We didn't just get here
	newRoute.name !== PageNames.QUIZ_SECTION_EDITOR && // The new route isn't section editor // One of these is also true...
	(Boolean(newRoute.query.showBookmarks) || // We're viewing bookmarks
	Boolean(newRoute.params.topic_id) || // We're viewing a topic
	oldRoute.name !== newRoute.name); // We're just not on the same page within the panel
	});

The issue here is that because the Quiz side panel business is wrapped this way and the SearchFiltersPanel wants to be it's own little SidePanelModal when !windowIsLarge we get nested SidePanelModals in mobile views and don't have a direct way to say "show the back arrow when in the 'choose a sub-category' view".

Basically, I got to where I'd have to update that watcher in SectionSidePanel and figured it might be worth removing that overly complicated code for answering the question "back arrow or close icon?"

3. The SidePanelModal should probably have a title prop added where we can just put the text we want to see in the heading-area of the side panel - currently it uses a #header slot (which I think could do well to be renamed to something like #sidePanelHeader) -- but it's such a common part of the side panel designs now that it'd probably be best to standardize it.

---

So, that said, I have pushed updates that should be working @radinamatic -- I watched the Chrome video you linked and I'm wondering if this is to do with the mobile stuff I mentioned as the screen started small, then was widened. I ran into something similar to this today.

I've tested in mobile on Learn and Coach today and the main things that won't be correct are:

• Side panels will not have titles at the top yet
• When selecting a sub-category (ie, click a category, see the second set of options) you will see an X icon to close it - so there is no way back yet but will be addressed by addressing the issues above

[marcellamaki]

With regards to:

reworking to how SearchFiltersPanel renders itself and updating TopicPage and LibraryPage to handle the responsibility of things like how/where it is shown depending on the window size

I would say this is in scope of this issue. I guess in the issue itself I cautioned against refactoring, but that was really in terms of "how search works". Changes to support the conditional rendering make sense. If talking through some of the pros and cons to approach would be helpful, I'm happy to do that.

And, a couple of other things I noticed just looking in the browser:
This is only in coach, but it looks like everything is selected and inactive. I know that the actual integration of useSearch is coming later, but this seems unintentional, even just for initial QA. Not sure if something just got a bit wonky here?

When making a selection, for example, when I choose 1 category, the other filters auto update and indicate that they are selected. On the one hand, this makes sense, because I think it means that only one option is possible for the other metadata fields, and therefore, the search is "including" these additional criteria. However, it feels a little odd to me, I guess because the search in the URL is strictly about the categories, not the other fields (see in screenshot). I'm not saying this is necessarily a blocker, maybe it is the expected behavior, or it would be technically complex to do it differently. But, I think we need to ask @jtamiace about whether this is what we want or not.

Design [nit-picks, sorry]: the "activity" buttons should be 4 across not 2; the dropshadow on the accordions is such a small thing but it is driving me bananas for a unknown reason 😂

[AlexVelezLl]

Hi! I have just left some questions that were not entirely clear to me 😅

[AlexVelezLl]

[Non blocking] The render conditions of this component are getting each time more complex, it would be good if in the future we can find a way of making this more easy to follow. Perhaps breaking down this component into more specific use cases? like BookmarksResourceSelection, SearchResourceSelection, etc.

[nucleogenesis]

Oh yes for sure! All of the changes here to ResourceSelection are basically for demonstration purposes - although @marcellamaki and I are drafting an issue which will hopefully refactor this component quite a bit

[AlexVelezLl]

Is there a posibility that all these conditions arent met and we have an empty div for AccordionSelectGroup? I suspect if we dont have any of these we wouldnt even get to this point, but just curious if we have considered this.

[AlexVelezLl]

I think Marcella's comment about disabled selected values is because we are considering this isEnabledButNotSelected value as correct value for isChecked, and I wonder, why would we check something if its not selected, even if its enabled?

[nucleogenesis]

This just makes it so that you see the changes to what is selected even if it's not directly clicked by the user (ie, you select Spanish, then the other available filters are disabled/checked-automatically if there are no Spanish resources for them).

My latest updates make use of this (fixing the issue where everything is checked & disabled because I misread/understood the enabled computed properties).

However, I can probably just remove the isEnabledButNotSelected altogether if we handle selections like we do in Learn because part of the issue is to do with a reactivity issue somewhere if I recall correctly.

[AlexVelezLl]

I dont understand that much these conditions. We disable it if its enabled but not selected? I found it a little bit confusing 😅

[AlexVelezLl]

With this, the channels are working as a checkbox rather than as a radio button, and we can select both of them but just one appears as selected

I wonder if we should change the radio buttons to be checkboxes or change this handleChange method to support the radio button behaviour to have just one selected value and remove the rest.

[nucleogenesis]

Thank you Alex, I've resolved this issue

[AlexVelezLl]

Is this needed to center the icon?

[nucleogenesis]

Yep!

[pcenov]

Hi @nucleogenesis in addition to what's been already mentioned by you and Marcella, I was able to identify the just the following potential issues:

1. When managing quizzes the Activities section of the SearchFiltersPanel should not be displayed - just mentioning it as it was immediately strange to see it displayed there but if you are showing it now just for illustration, it's fine then.

2. When comparing the current implementation with Figma I noticed that only in the Channel filter the options are listed as radio buttons while in the rest of the filters I see checkboxes. In Figma all filters are shown with radio buttons and also the current behavior of the filters in the Library page allows for selecting only one option.

3. The 'Show resources' filter is missing:

[radinamatic]

Content in the search sidebar is now visible, yey! 👍🏽

To add on comments by @pcenov (and I completely agree, the Activities section is completely superfluous here, since only the Practice type of resources can be used in quizzes):

1. Channels should be pre-filtered to only display those that contain exercises

   

2. I find it unclear and confusing that when a second level category is selected as filter, that selection is not clearly displayed: if I select to filter Mathematics and I close the modal, only the School is marked/highlighted. What is user supposed to do in order to review/remind themselves what they selected, open the modal again? 🤔

---

3. I get that the actual filtering is not happening (yet), but what I find even more confusing is the missing Go/Proceed/Search button or such, after the user has made their various selections, to actually perform the search... 😕
   If they type in a keyword they can use the ➡️ button, but if they want just to filter by other options without keywords, how do they actually initiate/perform the search? It's not clear to me from Figma...

Keyboard navigation at this point does seem to be working correctly, but with many still moving parts and WIP, I'm reserving the judgment and will re-test as dev work progresses.

cc @jtamiace for questions 2 & 3.

[radinamatic]

Update on my points 2 & 3 above, as my concerns and confusion seems to be caused by the search not being performed at this stage. Once the current filtering workflow as in Learn > Library is fully implemented here, concerns will probably be resolved.

[nucleogenesis]

@radinamatic @pcenov

Some updates to review and/or things bear in mind:

• The activity icons showing and resources not being filtered by kind in this particular case is just for display purposes -- I'll be removing this from the quiz creation altogether before merging so that @ozer550 can basically drop in the search filters where they need to live.
• If the accordion and the selection stuff looks and feels right, then we'll hook up things like the "SearchChips" in Integrate Search Filters related components into lessons workflow #12788 where it'll be a functional search experience in Lessons
• I have updated the ActivityButtons flow - please see that they look okay in Learn Library Page, Topic Page, and in the quiz creation - while they don't look exactly like the Figma, they flow in a way that fits the available space responsively
• The checkboxes & radio buttons now should work and clicking them should auto-apply other filters and such. This feels particularly weird because typically when a user clicks a filter, we'd close the filters and show them the results. However, if this workflow isn't desirable, then the search module will need to be refactored a bit.

(cc @marcellamaki)

[pcenov]

Hi @nucleogenesis,

Seems that the changes made to the ActivityButtons flow are a step in the right directions but that's causing issues in the Library page and the Topic page:

ActivityButtons.flow.mp4

For the checkboxes and radio buttons - can't we have the same drop-downs as the ones at the Library page? The current implementation where I select a checkbox and all the other checkboxes become disabled + other filters get disabled in the background is not very intuitive and seems too complicated? Also when the filters are collapsed it's easy to get lost and forget what were the selected values...

checkboxes.and.filters.mp4

Also if there are no options that can be selected from a filter, shouldn't it be completely disabled:

not.selectable.mp4

Lastly for the Categories filter I noticed that we are currently missing the Uncategorized option.

[nucleogenesis]

@pcenov I've updated to fix the design issues and the missing Uncategorized category

For the checkboxes and radio buttons - can't we have the same drop-downs as the ones at the Library page? The current implementation where I select a checkbox and all the other checkboxes become disabled + other filters get disabled in the background is not very intuitive and seems too complicated? Also when the filters are collapsed it's easy to get lost and forget what were the selected values...

I totally get that - do you think that this would be better if you were being taken to the search results after making a selection? This will be the UX - so the user won't see the filters selected-ness or disabled-ness unless they re-open the search panel after their results are shown. (cc @jtamiace @marcellamaki )

---

Also if there are no options that can be selected from a filter, shouldn't it be completely disabled:

I think so but this would take some updates to the Accordion - we could probably disable the button that toggles the Accordion but I'm not super sure if that'd work.

[pcenov]

Hi @nucleogenesis, I think it looks much better now! Here are the latest issues I was able to spot:

1. Now we have the "Uncategorized" category but once I select it it cannot be deselected:

unrecognized.mp4

This is also valid when I select that option at the Library/Topics page but there we have the 'Clear all' and delete filter options. So if possible clicking on "Uncategorized" should first enable the filter and then clicking again on it should remove the filter.

2. Selecting a category at the Library/Topics page results in not showing the modal (as was the case previously) and instead the options are displayed at the bottom of the filters section:

categories.mp4

3. We are probably going to need a back arrow shown when selecting categories, as currently the user is basically forced to make a selection while it should be possible to browse the categories and go back without making a selection if an appropriate category is not available for selection. At the Library/Topics page there's a 'Close' button:

no.back.arrow.mp4

4. Because of the radio buttons in the "Channel section" once I've selected a channel, there will always be at least one selected channel. Also when I select a Language that is available only in one channel, then the other channel remains available for selection while it should be disabled:

language.mp4

[nucleogenesis]

@marcellamaki @pcenov I've fixed the issue w/ the filters showing up at the bottom of the page.

re: the channels filters being applied as the user navigates coach, I think that'll be done in #12819 when things get wired up in full

[pcenov]

Hi @nucleogenesis, I confirm that the issue with the filters showing up at the bottom of the page is fixed now.
No new issues observed while manually testing, so I'm going to approve this PR.

[rtibbles]

A couple of small tweaks that I think will make the search integration much more complete within the scope of this PR.

[rtibbles]

We are already defining the topic below, we should pass that in as the descendant option to useBaseSearch to properly hook this up to the descendant restricted searching when applicable.

[rtibbles]

We should just call search unconditionally, like we do in the library page: https://github.com/learningequality/kolibri/blob/develop/kolibri/plugins/learn/assets/src/views/LibraryPage/index.vue#L515

(although I am not quite sure why we are calling it in the created hook and not the setup function).

[nucleogenesis]

Thanks @rtibbles I've updated LibraryPage to call search in setup, passed the topic ref in for the descendant param & call search unconditionally in ResourceSelection.

[rtibbles]

Code changes look good, let's unblock this!