Add a toggle to switch to Special:Search list to switch between list/imagegrid
Open, Needs TriagePublicFeature
Actions

Assigned To

Authored By

	Zache
	Mar 23 2025, 12:12 PM

Description

Wikimedia Commons currently have two distinct search interfaces: the newer Special:MediaSearch, which displays search results as an image thumbnail grid, and the older Special:Search, which shows results in list format. While Special:MediaSearch excels in visual browsing and image selection convenience, Special:Search offers better search capabilities and allows displaying up to 5000 results at once.

As a user, I want to enhance my experience on Special:Search by adding image grid functionality and ability to further filter the list using client side filtering.

Step 1: Adding Image Grid Toggle

Implement a feature in Cat-a-lot that allows toggling Special:Search results between the traditional list view and a new image grid view.
Ensure that the image grid view remains compatible with Cat-a-lot's existing image selection functionality.

Step 2: In-Page Text Search Filtering

Adding functionality to filter the displayed search results directly on the page by filename or other text criteria. Preferably option for using REGEXP in text seach.
The in-page filter should operate client-side (ie. javascript impelemntation)
After applying the filter, only images matching the entered search expression should be visible.
When performing category actions, if previously selected images are hidden due to the applied filter, Cat-a-lot should prompt the user to confirm whether to deselect these hidden images before proceeding.

How to test solution

Add mw.loader.load('//commons.wikimedia.org/w/index.php?title=User:RitaNamono/cat-a-lot-grid-view.js&action=raw&ctype=text/javascript'); to your common.js file to test functionality.

Goals:

Improve usability and efficiency of browsing large sets of images.
Allow refined post-search filtering directly on the results page.
Maintain compatibility and improve user interaction within Cat-a-lot.

Related Objects
Search...

		Status	Subtype	Assigned	Task
		Open	Feature	RitaNamono	T389735 Add a toggle to switch to Special:Search list to switch between list/imagegrid
		Open		RitaNamono	T391676 Cat-a-lot: Implement State Persistence for DOM Changes

Event Timeline

Zache created this task.Mar 23 2025, 12:12 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 23 2025, 12:12 PM

Zache renamed this task from Toggle to switch Special:Search list to thumbnails to Add a toggle to switch to Special:Search list to switch between list/imagegrid.Mar 23 2025, 12:13 PM

Zache updated the task description. (Show Details)

Zache moved this task from Backlog to Outreachy (Round 30) on the gadget-Cat-a-lot board.Mar 23 2025, 3:17 PM

Zache mentioned this in T387982: Outreachy 30: Cat-a-lot javascript gadget development.Mar 23 2025, 5:03 PM

About implementation: It could also be done by creating a separate script responsible for toggling between the Special:Search list/image grid and applying filters, accompanied by minor modifications to MediaWiki:Cat-a-lot.js. However, I think it might be possible to achieve this simply by tweaking the CSS using javascript, eliminating the need for changes to MediaWiki:Cat-a-lot.js altogether. The relationship between these two scripts would be that Cat-a-lot would load the new script as well, although the new script could also be used independently.

About how to identify the current page via JavaScript:

Page-specific variables are defined on every page and can be viewed in the <head> section of the page's source code. These variables can be accessed using mw.config.get. For example:

mw.config.get('wgNamespaceNumber');
Some relevant variable examples:

"wgCanonicalNamespace": "Special",
"wgCanonicalSpecialPageName": "Search",
"wgNamespaceNumber": -1,
"wgPageName": "Special:Search",
"wgTitle": "Search"

Documentation for variables: https://www.mediawiki.org/wiki/Manual:Interface/JavaScript

Why should this be part of Cat-a-lot? Of course, they should be compatible, but otherwise I think they should be completely separate gadgets, as there may be people who like the gallery layout on Special:Search but don’t want to use the recategorizing feature of Cat-a-lot, and there may be people who use Cat-a-lot but are completely fine with the list layout of Special:Search. And the in-page search feature is yet again a separate feature (and, by the way, probably quite tricky to do with acceptable performance but at the same time without overloading the servers).

It was an integrated feature because when I was writing, I thought it didn't really need anything too complicated to switch between image grid/list in Special. Only after that was I thinking that it could be an independent script, and I left the first comment. About why it should be feature in Cat-a-lot (in separate file or not), it is because findability. If people wont know that feature exits the do not toggle it on.

About filtering: It depends on how we are filtering. If it is post-filtering the list, then there are at most 5,000 images, and filtering them is not a problem in terms of performance. This is especially true if the idea is to make a text search against filenames, and it will happen only when the user clicks the button, not in real-time.

In T389735#10674333, @Zache wrote:

About why it should be feature in Cat-a-lot (in separate file or not), it is because findability. If people wont know that feature exits the do not toggle it on.

Discoverability is a good point, but I don’t think Cat-a-lot is the best place for advertising it. Adding it to https://commons.wikimedia.org/wiki/Commons:Tools#Search is a must-have, and additionally it could be advertised in https://commons.wikimedia.org/wiki/MediaWiki:Search-summary – which appears to everyone using Special:Search, whether or not they use Cat-a-lot, but without forcing the tool on them.

About filtering: It depends on how we are filtering. If it is post-filtering the list, then there are at most 5,000 images, and filtering them is not a problem in terms of performance. This is especially true if the idea is to make a text search against filenames, and it will happen only when the user clicks the button, not in real-time.

Oh, I thought you want full-text search on the result pages, i.e. also find matches outside of the displayed snippet, and that’s what could easily get very expensive. Searching in content already visible on the page indeed shouldn’t be a performance concern.

Tacsipacsi mentioned this in T389739: Integrate PetScan functionality into Cat-a-lot for generating image lists.Mar 25 2025, 7:53 PM

Zache assigned this task to RitaNamono.Mar 26 2025, 5:13 AM

I assigned this to Rita based on discussion on slack. So there is indicator that this is worked on.

Hey @Zache do I create a sub task for testing the changes made for this test?

What is the flow/convention for moving tickets?

Why would a subtask be needed? :)

In T389735#10698864, @Aklapper wrote:

Why would a subtask be needed? :)

This answers my question. I needed clarity since I had seen sub tasks being created to test changes within a task. I just had to be sure.
Thanks @Aklapper, it's not needed is my conclusion.

@Aklapper There was a dual purpose for test tasks. I wanted to get clean tickets where it's described what the feature does and there is documentation on how it is expected to be tested (ie. howto load the code etc), so it's easy for other people in our Outreachy Slack channel to test them. Ticket can be used also as a reference when the change is requested to be merged into the official Cat-a-lot code in Wikimedia Commons talk page. Also, if your purpose is to give hands-on experience with Wikimedia's developer environment, it's nice that people will create Phabricator tickets also just to show how it works.

@RitaNamono Thank you, I checked the implementation. It was very nice and clean code. About features, I think that the images could also grow larger if the column count is decreased and the text snippet (i.e., text in searchresult) could be hidden when the system is in image grid mode so there would be more images in the same space.

About visual tweaking: The div.cat-a-lot-view-toggle could be set to be the same width as the search field above and the div.mw-search-profile-tabs below.

Thanks for the feedback @Zache , I wanted to keep all the changes contained in one separate file without making changes to various files.
I am going to work on the refinements and recommendations to improve the solution.

I now tested how this works on mobile. It was working quite well, but thumbnail image borders/margins are forcing the images to be very small. In practice, images could take up all available space in the box without margins/paddings or with minimal margins/paddings.

Another visual issue was that in mobile it starts to be very noticeable that filenames and thumbnail images are aligned to the left and not to the center. The same issue exists in the desktop version too, but it is not visually so striking on desktop.

Howto test different skins

You can simulate Wikimedia Commons mobile view on desktop by changing the skin as "MinervaNeye" ( Preferences -> Appearance ) and narrow the browser window. There is also url parameter useskin=minerva ( https://commons.wikimedia.org/wiki/Special:Search?useskin=minerva ) which switches the skin temporarily.

On mobile device easiest way to open special:search is to search if from search bar by page name.

Screenshots as example:

Hey @Zache, I made changes to address the feedback you shared. Do let me know how the experience is for you now.

RitaNamono updated the task description. (Show Details)Apr 3 2025, 10:57 AM

IMG_CFE10175DCA0-1.jpeg (2×1 px, 778 KB)

Hi Rita, there were still some visual artifacts on mobile. My guess is that when tested only with a desktop browser, the window wasn't narrow enough to trigger the issue. I tried to find working CSS combinations, and this was my take on it.

"I added min-width to containers so that they have enough space.
"I also wrapped the filter text field, reset button and regexp checkbox in a filter-main container so that the cat-a-lot-filter-count text would align below them if the screen is narrow.
I also modified grid images to be a little bit larger.

Here is my changes: diff

What I was not able to solve yet was how the Cat-a-lot select should be handled. Most likely it would require some API function which would trigger Cat-a-lot refresh when grid/list mode is changed and it would re-add the cat_a_lot_label and cat_a_lot_selected CSS classes and event handlers to the correct places."

Hey @Zache thank you for the feedback and update.
The min-width containers, filter control grouping, and larger grid images fix the visual artifacts I missed during my testing. The responsive stacking approach makes perfect sense for narrow screens. Thanks for making the tool usable across all devices especially the smaller ones.

I had tested the UI behavior via desktop browser responsive mode on Chrome, Firefox, and Safari and also tested the UI on mobile using 2 mobile phones that have a viewport size of 428px by 926px and a viewport size of 414 x 896 pixels respectively also via safari and chrome browsers

viewport size of 428px by 926px

viewport size of 414 x 896 pixels

I suggest using a state preservation approach to solve how the Cat-a-lot select should be handled rather than an API trigger approach. It’s less invasive and better for performance in general.

Should I implement this as a microtask?

In T389735#10732811, @RitaNamono wrote:

I suggest using a state preservation approach to solve how the Cat-a-lot select should be handled rather than an API trigger approach. It’s less invasive and better for performance in general.

Should I implement this as a microtask?

Yes, that would be great. Just create a subticket for it. I am also interested in the potential solution because T389739 and T390572 are blocked by this as well. I.e., the general problem is how to keep Cat-a-lot's state synced when DOM content has been changed by an external actor (i.e., list has been reloaded, some items have been removed, etc.).

RitaNamono changed the status of subtask T391676: Cat-a-lot: Implement State Persistence for DOM Changes from Open to In Progress.Apr 11 2025, 1:54 PM

RitaNamono moved this task from Outreachy (Round 30) to Outreach (testing) on the gadget-Cat-a-lot board.Apr 11 2025, 1:57 PM

RitaNamono closed subtask T391676: Cat-a-lot: Implement State Persistence for DOM Changes as Resolved.Apr 12 2025, 7:57 PM

Aklapper reopened subtask T391676: Cat-a-lot: Implement State Persistence for DOM Changes as Open.Apr 12 2025, 8:36 PM

	F59040838: IMG_9937.png
	Apr 11 2025, 10:09 AM

	F59040839: IMG_9938.png
	Apr 11 2025, 10:09 AM

	F59040826: IMG_8889.png
	Apr 11 2025, 10:09 AM

	F59040827: IMG_8888.png
	Apr 11 2025, 10:09 AM

Add a toggle to switch to Special:Search list to switch between list/imagegridOpen, Needs TriagePublicFeatureActions

Description

Related ObjectsSearch...

Event Timeline

Add a toggle to switch to Special:Search list to switch between list/imagegrid
Open, Needs TriagePublicFeature
Actions

Related Objects
Search...