I thought we already had a task for Special:WhatLinksHere, but I haven't found it (so maybe it doesn't really exist).
Before:
Description
Description
Details
Details
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| mediawiki/core | master | +49 -85 | Convert Special:WhatLinksHere from XML form to OOUI form |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T49145 Formally deprecate jQuery UI after we've stopped using jQuery UI in extensions and core (replacing it with OOUI). | |||
| Open | None | T100270 Replace use of jQuery UI and MW UI with OOUI across all Wikimedia-deployed extensions and core | |||
| Resolved | Esanders | T86617 VisualEditor's save dialog should use OOUI checkboxes | |||
| Open | None | T100161 Convert all of MediaWiki core to OOUI PHP (tracking) | |||
| Open | None | T107037 Convert all MW core special pages to OOUI | |||
| Open | None | T117754 Convert Special:WhatLinksHere to OOUI |
Event Timeline
Comment Actions
Change 276966 had a related patch set uploaded (by Ajayrahulp):
Convert Special:WhatLinksHere from XML form to OOUI form
Comment Actions
Change 276966 merged by jenkins-bot:
Convert Special:WhatLinksHere from XML form to OOUI form
Comment Actions
Two actionable (and hopefully doable) suggestions:
- The "Namespace" and "Invert selection" fields should be on the same line (and behave like a single field).
- Something I had in mind for a while was a 'namespacemultiselect' field type in HTMLForm, that would display these two fields (plus an "Include associated namespace" one, optionally) and return an array of namespace ids as its data (a bit like HTMLMultiSelectField). Please note that this is not a polished idea and I never tried implementing it :D
- I did, however, implement MediaWiki\Widget\ComplexNamespaceInputWidget for the OOUI version. It was briefly used on Watchlist (before that OOUI conversion was reverted too, T99256).
- The "Hide blah" checkboxes should also be on the same line and behave like a single field.
- You can probably use 'multiselect' field type easily here, for a start.
- We had some other OOUI HTMLForm special page which used a little bit of custom CSS to display similar checkboxes inline, I can't remember which one now.
Quick mockup (edit of the screenshot above):
Comment Actions
Quick mockup (edit of the screenshot above):
Better than the reverted stuff, but still so much unnecessarily space consuming.
Can't the original layout be kept as much as possible?
Why are labels above controls?
Why is ns selector x-times wider than the widest item in it?
Etc...
Comment Actions
Even if I might repeat myself. To @Danny_B's points above:
Why are labels above controls?
Because there's lesser cognitive workload when labels are above controls. People are quicker when fulfilling their tasks on forms with labels above fields. See for example https://www.uxmatters.com/mt/archives/2006/07/label-placement-in-forms.php
Why is ns selector x-times wider than the widest item in it?
What is the problem with this?
Comment Actions
This is not directly related to the task, but I thought some of this may be useful to someone. I'm the maintainer of the AdvancedBacklinks extension that lets you track links through transclusions and can get you easily in a psychiatric hospital. Anyway, this extension has a special page very similar to Special:WhatLinksHere, just enhanced with a few neat features. I recently rewrote some of this special page to use OOUI and the end result is this:
If you want, you can test it out here: https://nonsa.pl/wiki/Special:AdvancedBacklinks?uselang=en (the wiki is unfortunately in Polish)
The relevant merge request with all changes needed to make this work is here: https://gitlab.com/nonsensopedia/extensions/advancedbacklinks/-/merge_requests/77/diffs
There a few caveats, though. These filter checkboxes to my best knowledge require you to break URL compatibility. Another option would be to invert their semantics, that is change their labels to Hide X, not Show X, but frankly that's horrible UI design. You could also support the old URL params as backwards-compat, probably. As we didn't care about URL compatibility, I redesigned it completely. I also completely removed the use of the FormOptions class, it was just annoying.
As for the core special page, I think the most similar special page in core that has already been converted to OOUI is Special:NewPages, may be worth looking there.