I do have interest. Please propose.

https://github.com/joomla-projects/j4adminui/blob/master/build/media_source/com_modules/js/admin-select-modal.es6.js

@brianteeman That JS is architecturally wrong which is likely why it never made it to beta. It has hardcoded HTML inside the JS. The correct approach is rendering the HTML sever-side (as it's already done) and filtering it client-side. I think I can just do a match for the card-header and card-body inside the new-modules DOM structure and add a BS4 element hiding class to the module cards that don't match.

I'm a bit busy with some work of my own today. When I have some time tomorrow or over the weekend I'll start working on it. It's easier coding it than trying to explain it :)

Just shared it if it would help.

Understood and thank you! I didn't meant to sound ungrateful. Sorry, coffee has trouble kicking in today...

Would be great to have a filter there!

I think there are many views in the joomla backend that needs filtering (ex. System Dashboard).
A generic version would be nice but don't know if it's in the scope and if it's excepted for 4.0.

A generic solution is a VERY tall ask. It's feasible, but we would have to duplicate a lot of the displayed information as data attributes to provide a generic interface for the code. This is definitely something for 4.1.

Filtering the modules list, however, is a must-have for 4.0. Right now it's downright unusable. Have you tried building a realistic site? I did.

Actually, I am doing the same thing I've done with J3. I'm building a site that's pretty much a slim-down version of an extension developer's site complete with product pages, support, downloads, a blog etc. I am using a set of custom CLI scripts to populate it with large amounts of sample content using Faker. I still get to build the categories, modules and some of the content by hand so I get a really good feel of how usable Joomla is for building a site.

The major problem I face in J4 is that the modules list is impossible to read. In J3 everything is stacked vertically which means that my eyes stick on one side of the screen as I'm scrolling an alpha-sorted list. With J4 I have cards in columns and rows. I have to move my gaze left to right, find the target, pause, read, move to the next column, repeat for each row. This gave me a headache. I ended up using the browser's find in page feature which is a subpar experience.

Let me know if I should still try to implement this for 4.0. We still have time. It's a beta. I don't even need to add any language strings – we already have generic language strings for searching items!

I'm happy for the module searching. Obviously subject to all the usual code quality checks etc I'm happy to commit to merging

one additional little wish: pre-save the last search phrase, can be in local storage

@nikosdion I have interest, too. I can fully confirm what you've said about basic neurobiology for interface design. I deal with that since some 20 years for critical software where operators have to react fast in case of a disturbance.

Hi @nikosdion , i agree with you. Big and large cards are difficult to read. For a test website I made this modification to the file /administrator/components/com_modules/tmpl/select

Just add on line 26 (under the H2) this code:

<button onclick="changestyle()">Change style</button>
<script>
function changestyle() {
  var element = document.getElementById("change-me");
  element.classList.toggle("singleline");
  var cards = document.getElementsByClassName("card");
  var i;
  for (i = 0; i < cards.length; i++) {
	  cards[i].classList.toggle("d-flex");
	  cards[i].classList.toggle("flex-row");
	  cards[i].classList.toggle("single-line-card");
	  cards[i].classList.toggle("align-content-center");
  } 
} 
</script>
<style>
.singleline {
	grid-template-columns: 1fr!important;
}
.single-line-card .card-header{
	min-width:200px;
}
.single-line-card .btn{
	max-width:100px;
}
</style>

it's old fashioned javascript, it's nice to read and can be improved (a lot!) but maybe it's a start. It's not a search as you asked but as a single line list i think it's easier to read.

Example:

@PixedBo The big cards are not bad – especially if you have a big and wide monitor. The problem is that there are a million of them :) My idea was to add a focused by default search box with a keybaord event handler. As you type in the box the displayed cards are filtered based on the title and description. This is easier for the user since they probably have in mind when they are looking for (module name or what it's supposed to do). Once you get down to 1 to 5 results it's easy to select the right one. That's what I've seen on other sites e.g. Google and I found it much more practical than I'd expect. All I have to do is find some time to implement the code.

I agree, a search would be extremly useful, assuming that you know what you are looking for. I think that a compact view would be useful to neophites who are looking to the module system for the first time and trying to understand what they can find here. Actually a filter system would be great too... something like "all modules for showing artciles", or "all modules for user display/logni/management", with a full working website the risk is to have a page with 50/60 blocks.
Something like a "category" for modules, so the module developer can choose where to assign his brand new module for the filtered search

Here's your PR.

Please remember to run node build.js --compile-js build/media_source/com_modules/js before testing.

@nikosdion Can we close the issue as we usually do when we have a PR for it? (I know, GitHub would do it differently.) Or shall we leave it open because the PR solves only parts of it?

@richard67 Per the comment by @wilsonge I believe that my PR covers the intended scope of this issue. The other points discussed are desired features beyond the scope of the issue. So I'd close this issue.

Closing as having a Pull Request. Please test #29463 .