Page MenuHomePhabricator

Convert Special:WhatLinksHere to OOUI
Open, MediumPublic


I thought we already had a task for Special:WhatLinksHere, but I haven't found it (so maybe it doesn't really exist).


Event Timeline

Florian raised the priority of this task from to Medium.
Florian updated the task description. (Show Details)
Florian added a project: UI-Standardization.

Change 276966 had a related patch set uploaded (by Ajayrahulp):
Convert Special:WhatLinksHere from XML form to OOUI form

Change 276966 merged by jenkins-bot:
Convert Special:WhatLinksHere from XML form to OOUI form

Sethakill claimed this task.
Sethakill removed a project: Patch-For-Review.

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):

Danny_B added a subscriber: Danny_B.

Needs design team's eyes obviously...

@Ajayrahul We've a little issue reverting the localisation of your code: your repurposed messages to give them a new meaning.

This choice makes it's not straighforward to revert: we need to track on TranslateWiki translations update, revert them, prepare a change.

When you change the meaning of an element interface, please create a new message instead of amend existing ones.

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?

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

Why is ns selector x-times wider than the widest item in it?

What is the problem with this?

Jdlrobson added a subscriber: Jdlrobson.

The mobile version of this page should be converted as well.

The mobile version of this page is the same as the desktop version.

matej_suchanek edited subscribers, added: Sethakill; removed: wikibugs-l-list.

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: (the wiki is unfortunately in Polish)
The relevant merge request with all changes needed to make this work is here:

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.