Page MenuHomePhabricator

Consider minimizing the presence of Partial Blocks UI elements on Special:Block
Open, Stalled, LowPublic

Description

Fields that are not editable shouldn't be visible, unless if you select the option. Admins are potentially curious people and will certainly click on the buttons to see everything that can be done.

As a volunteer admin, I need a quick and immediate access to the options I need on that page. Less scrolling will help! :)

SitewidePartial

From T233209: Collapse Partial block options on Special:Block:

Block a user is an action that need to be done in a timely manner, with simple steps. If I'm asked to block at-will a user for vandalism, I just have to select "Expiration", "Reason", and it is done.

At the moment, I see on Special:Block a lot of options I don't need. See the screenshot: my most important commands are spread all across the page:

Admins need a quick access to tools, and blocks shouldn't be a scrolling challenge. Since partial blocks are a particular case, the greyed fields for partial blocks should be hidden until "partial" radio button is selected.

I've tried to remove them using CSS, which is far from being a good option (I may need those tools in the future), and the code is not that optimized for it since it doesn't have identified names: #ooui-php-10, #ooui-php-11, #ooui-php-12 {display:none;}. I don't have the skills to create a gadget that would show and hide those 3 blocks.

Details

Related Gerrit Patches:

Event Timeline

Restricted Application added a subscriber: MGChecker. · View Herald TranscriptFeb 28 2019, 6:26 PM
Trizek-WMF updated the task description. (Show Details)Feb 28 2019, 6:30 PM
TBolliger triaged this task as Low priority.Feb 28 2019, 6:54 PM
TBolliger moved this task from Untriaged to Backlog on the Anti-Harassment board.
TBolliger added a subscriber: Prtksxna.

The latest version of the Wikimedia style guide (or equivalent for interactions) dictates that UI elements should be enabled/disabled, not hide/show. These interaction patterns can change based on our users' needs but this is a question for @Prtksxna and the design team.

I agree that these new elements take a significant percentage of space, but before we make any changes I want to see if the new changes will be palatable over time. I'm going to leave this open in the Backlog to address later, hopefully with some feedback from other admins.

Ammarpad renamed this task from When Sidewide option is selected, fields for a Partial block shouldn't be displayed to When Sitewide option is selected, fields for a Partial block shouldn't be displayed.Mar 1 2019, 8:54 AM
TBolliger renamed this task from When Sitewide option is selected, fields for a Partial block shouldn't be displayed to Consider minimizing the presence of Partial Blocks UI elements on Special:Block.Mar 5 2019, 12:34 AM

This comment is partially CYA, but lets not forget about T194301: Introduce temporary element on Special:Block UI to invite users to participate in the Partial Block consultation which ran from July 19-23 in multiple languages.

Jules78120 added a subscriber: Jules78120.
DannyS712 added a subscriber: DannyS712.

The latest version of the Wikimedia style guide (or equivalent for interactions) dictates that UI elements should be enabled/disabled, not hide/show. These interaction patterns can change based on our users' needs but this is a question for @Prtksxna and the design team.
I agree that these new elements take a significant percentage of space, but before we make any changes I want to see if the new changes will be palatable over time. I'm going to leave this open in the Backlog to address later, hopefully with some feedback from other admins.

If the style guide says not to hide the elements, then it seems there is nothing to be done here. If it is okay to hide them, its pretty straightforward to implement. @Prtksxna can you take a look and let us know?

Restricted Application added a project: User-DannyS712. · View Herald TranscriptSep 18 2019, 4:56 PM
Trizek updated the task description. (Show Details)Sep 18 2019, 5:23 PM

This is still annoying since there is no proper way to hack this.

Hi. I agree with Trizek: Partial Blocks are great, but we dont use them very often, so greyed fields should be hidden as long as 'partial block" is not selected. It will save time when blocking a lot of vandals during RC patrol.

Change 537718 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Hide partial block options when not applicable

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

@Volker_E Are there any accessibility reasons for recommending enable/disable over hide/show?

DannyS712 changed the task status from Open to Stalled.Mon, Oct 28, 4:12 AM

@Volker_E Are there any accessibility reasons for recommending enable/disable over hide/show?

Awaiting feedback on accessibility

@Tchanders display: none will hide content from screen reader users as well, but if the show/hide is not sufficently ARIA mapped, it's not being clearly exposed to screen readers what's hidden, what's shown. I assume this was the reason for the comment above and the Partial options always shown disabled.
The other small thing to be cautious about is the whole page moving underneath when the disabled elements would be hidden by default and shown only on Partial.

One small detail for the form, the Sitewide/Partial radio buttons top margin to the parent checkbox seems overly big, it should be reduced, probably by a single page CSS rule for this page to 8px.

Thanks @Volker_E. I've filed your recommendation in T236679: Reduce top-margin for checkboxes on Special:Block. Given your recommendation against hide/show for the partial block options, I am inclined to decline this task.

@Prtksxna Do you have any final ideas for what we can do here?