Page MenuHomePhabricator

Convert Special:Block and Special:Unblock to OOUI
Closed, ResolvedPublic

Description

Convert Special:Block to OOUI.

Special:Block uses some complex stuff, would be nice to have fancy widgets for all of it first. Special:Unblock doesn't, but it would be silly to do it before we do Special:Block.

Related Objects

Event Timeline

matmarex claimed this task.
matmarex raised the priority of this task from to Low.
matmarex updated the task description. (Show Details)
matmarex added a project: UI-Standardization.
matmarex renamed this task from Convert Special:Block to OOUI to Convert Special:Block and Special:Unblock to OOUI.Jul 27 2015, 3:14 PM
matmarex updated the task description. (Show Details)
matmarex set Security to None.

Change 218281 had a related patch set uploaded (by Bartosz Dziewoński):
[WIP] SpecialBlock: Switch to OOUI form

https://gerrit.wikimedia.org/r/218281

Change 218281 abandoned by Bartosz Dziewoński:
[WIP] SpecialBlock: Switch to OOUI form

Reason:
I'm not going to work on this soon.

https://gerrit.wikimedia.org/r/218281

matmarex removed a project: Patch-For-Review.

Change 377048 had a related patch set uploaded (by Ladsgroup; owner: Amir Sarabadani):
[mediawiki/core@master] Migrate Special:Unblock to OOUI

https://gerrit.wikimedia.org/r/377048

Change 377048 merged by jenkins-bot:
[mediawiki/core@master] Migrate Special:Unblock to OOUI

https://gerrit.wikimedia.org/r/377048

@Ladsgroup This will be completely done and in production next week?

The block scheme won't be (it's not done yet) but the unblock page will.

Change 381483 had a related patch set uploaded (by Ladsgroup; owner: Amir Sarabadani):
[mediawiki/core@master] Remove unneeded js module in SpecialUnblock

https://gerrit.wikimedia.org/r/381483

Change 218281 restored by Ladsgroup:
[WIP] SpecialBlock: Switch to OOUI form

Reason:
I will work on it.

https://gerrit.wikimedia.org/r/218281

Change 381483 merged by jenkins-bot:
[mediawiki/core@master] Remove unneeded js module in SpecialUnblock

https://gerrit.wikimedia.org/r/381483

Change 218281 merged by jenkins-bot:
[mediawiki/core@master] SpecialBlock: Switch to OOUI form

https://gerrit.wikimedia.org/r/218281

OK, so now the following are all using OOjs UI interface components:

  • Special:Block
  • Special:Unblock
  • Special:AutoblockList
  • Special:BlockList

The only block-related items not converted are those provided by GlobalBlocking, namely Special:GlobalBlockList and Special:GlobalBlockWhitelist. Pending any further fixes, I think this is done, just two years after creation. :-)

Change 381990 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[mediawiki/core@master] SpecialBlock: Tweaks for OOUI HTMLForm

https://gerrit.wikimedia.org/r/381990

Change 381990 merged by jenkins-bot:
[mediawiki/core@master] SpecialBlock: Tweaks for OOUI HTMLForm

https://gerrit.wikimedia.org/r/381990

Yeah, that would be nice. Or even if we had mobile/desktop versions.

Can I ask what do you see incorrect in the new interface?

OOUI is one thing that can't be turned off, you can jump to another theme of by changing to monobook skin but you would lose a lot already.

Nothing is "incorrect", I just don't particularly like the new interface. I know that's not a great reason for wanting things to stay the way they are, but the dropdown menus are massive (often going off the bottom of my screen) and I definitely preferred the smaller and more readable options of the previous version.

+1 Primefac - For one, the interface alone takes up too much space on a laptop screen, and the dropdown block reasons on enwiki (https://en.wikipedia.org/wiki/MediaWiki:Ipbreason-dropdown) now take much more scrolling than they did previously.

From my IRC conversation with @Shawn a screenshot of the OOUIfied Special:Block on frwiki:

image.png (1×1 px, 235 KB)

and three topics as feedback (@Shawn, please add if I miss something):

  • New dropdown menu items are taking up more vertical space, making dropdown extend over viewport
  • Grouping of elements in Dropdown is not as clear as before, handled in T92452
  • Form has unnecessary whitespace, extending the form vertically, taking away from rest of the contents.

After more tests at home, I think you pretty much broke the Block page.

I forced the display of the original standard html select tag to show it was working properly before (see annotations on screen capture):

Example with standard select.png (2×3 px, 505 KB)

With the new OOUI design, the drop list is completely unusable : we can only see two elements in that case (see annotations on screen capture):
(the screen capture above was taken with Firefox screenshot and show a wider area than what was really shown on screen. This one is much realistic :)

Example with broken OOUI dropmenu.png (2×3 px, 748 KB)

Using the block page is a pain now. I'm trying to "un-break" this change in my common.css but it is very difficult as I'm not a CSS expert... I'm trying to revert back to standard select component witch was working very well before.

And as @Volker_E said, there is way too much space between items in the dropmenu but also between checkbox items at the bottom of the page (not shown in the capture as now I need to scroll to view all page data, although there is not so much data to display...). This is really not easy to read. I have to step back from my screen to have an overview of the list. And now I have to scroll to view all information on that page when all was visible with previous design.

Its is very annoying when you have a 4K monitor with a 3840x2160 resolution and you cannot entirely view a droplist of 17 items and when you need to scroll on a page with not so much information....

As @matmarex has pointed out T158934: Automatically change popup direction if there is no space has been filed before and this would handle the fourth point brought up by @Shawn on dropdown menu should open to vertical side with more space available.

Can I ask what do you see incorrect in the new interface?

The biggest problem I face is I'm not able to use only tab and arrows to choose block options, I need to use enter key which may apply the block before I mean to do.

OOUI is one thing that can't be turned off, you can jump to another theme of by changing to monobook skin but you would lose a lot already.

I'm already using monobook, but still I cannot see ways to disable OOUI

This has caused a regression as has been reported at T177705, similar to what happened at T171405.

Just wondering: why does the deletion page feature a border around the form and these forms do not? The dropdowns also seem to behave differently.

After more tests at home, I think you pretty much broke the Block page.

With the new OOUI design, the drop list is completely unusable : we can only see two elements in that case (see annotations on screen capture):
(the screen capture above was taken with Firefox screenshot and show a wider area than what was really shown on screen. This one is much realistic :)

Example with broken OOUI dropmenu.png (2×3 px, 748 KB)

Its is very annoying when you have a 4K monitor with a 3840x2160 resolution and you cannot entirely view a droplist of 17 items and when you need to scroll on a page with not so much information....

I'm sorry it took this long to push through, but we've just improved this a lot (T158934) – the dropdown will now open in the direction in which it has more space. This change will go live next week (5-7 December), for now you can test it on https://en.wikipedia.beta.wmflabs.org/wiki/Special:Block (I can grant you administrator rights there if you ask, just comment with your username on that wiki).

I am hoping our dropdown is now no worse than the normal one (except for the unavoidable inability to extend outside of browser's window).

image.png (980×1 px, 202 KB)

Also, we're currently working on making the dropdowns use native HTML <select> in some cases, for mobile devices: T180730. I don't think this is going to be enabled for desktop, but since it will be a thing that we will be supporting, it should be possible to create a reliable gadget/script to force it to be always used. Please follow that task if you're interested.

Just wondering: why does the deletion page feature a border around the form and these forms do not? The dropdowns also seem to behave differently.

I'm not sure if there's a reason for the inconsistent borders. By default they are not added, you have to explicitly enable them. I would have to check how it looked like before, but probably there was some kind of border on the old deletion form and there wasn't on the old block form.

Deletion form uses a native HTML <select> with some OOUI styles applied, rather than a custom OOUI dropdown. I'm not sure if there's a reason for this either, possibly there was some important gadget that fell apart otherwise, and there was no good reason to break it (on the block form, we use the value of the "Expiration" dropdown to show/hide other form fields, which is easier when it's using custom OOUI dropdown, but there's no such handling on deletion form).