Page MenuHomePhabricator

Consider minimizing the presence of Partial Blocks UI elements on Special:Block
Open, 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.

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 Product 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.Oct 28 2019, 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?

I am not against hiding the form elements that aren't being used, but, as Volker pointed out, if we do do this we should make sure that the ARIA mappings are correct and we're using aria-expanded and aria-controls correctly. We'll also need to test with screen readers to make sure its working properly. You can read more at — https://www.accessibility-developer-guide.com/examples/sensible-aria-usage/expanded/

In the case that we can't ensure that the hiding/showing is accessible, we should stick with the status quo of full accessibility at the cost of extra scrolling.

Change 537718 abandoned by DannyS712:
Hide partial block options when not applicable

Reason:
Should be done using hide-if

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

Change 570948 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/570948

Using HTML form's hide-if should take care of accessibility concerns

DannyS712 changed the task status from Stalled to Open.Feb 10 2020, 6:21 AM

I am not against hiding the form elements that aren't being used, but, as Volker pointed out, if we do do this we should make sure that the ARIA mappings are correct and we're using aria-expanded and aria-controls correctly. We'll also need to test with screen readers to make sure its working properly. You can read more at — https://www.accessibility-developer-guide.com/examples/sensible-aria-usage/expanded/

In the case that we can't ensure that the hiding/showing is accessible, we should stick with the status quo of full accessibility at the cost of extra scrolling.

Using eliminate the issues

In the case that we can't ensure that the hiding/showing is accessible, we should stick with the status quo of full accessibility at the cost of extra scrolling.

The reason is understandable, but may not be accepted by people who use this form multiple times a day. And we still miss a convenient way to locally hack this (like in my common.js).

Using HTML form's hide-if should take care of accessibility concerns

@DannyS712 Thanks for working on this. Can you share screenshots or a screen recording of the end result?

Using HTML form's hide-if should take care of accessibility concerns

@DannyS712 Thanks for working on this. Can you share screenshots or a screen recording of the end result?

You can see it at http://patchdemo.wmflabs.org/wikis/b02676d0a7043c7e914685e4c1495dd0/w/index.php/Special:Block/Patch_Demo (login with username Patch Demo, password patchdemo1.) - meets the acceptance criteria and works

Using HTML form's hide-if should take care of accessibility concerns

@DannyS712 Thanks for working on this. Can you share screenshots or a screen recording of the end result?

You can see it at http://patchdemo.wmflabs.org/wikis/b02676d0a7043c7e914685e4c1495dd0/w/index.php/Special:Block/Patch_Demo (login with username Patch Demo, password patchdemo1.) - meets the acceptance criteria and works

Thanks! That looks good to me. @Prtksxna could you take a look at this to make sure your concerns are addressed?

You can see it at http://patchdemo.wmflabs.org/wikis/b02676d0a7043c7e914685e4c1495dd0/w/index.php/Special:Block/Patch_Demo (login with username Patch Demo, password patchdemo1.) - meets the acceptance criteria and works

Thank you! I just tried it and noticed that the partial block menu is open while the page loads and then disappears. I guess this is due to the test wiki it is implemented on?

(I'm adding the User-notice tag, because people will be happy to know when this would be deployed.)

You can see it at http://patchdemo.wmflabs.org/wikis/b02676d0a7043c7e914685e4c1495dd0/w/index.php/Special:Block/Patch_Demo (login with username Patch Demo, password patchdemo1.) - meets the acceptance criteria and works

This looks good 👍🏽

Using HTML form's hide-if should take care of accessibility concerns

@Mooeypoo @Volker_E I don't know much about hide-if. Is it implemented in an accessible way?

Using HTML form's hide-if should take care of accessibility concerns

@Mooeypoo @Volker_E I don't know much about hide-if. Is it implemented in an accessible way?

I actually don't know much about hide-if in HTMLForm, but if it's implemented in HTMLForm, it sounds like it is coming from the backend already hidden, rather than dynamically shown/hidden by the Javascript?

Today I learned ;) https://phabricator.wikimedia.org/source/mediawiki/browse/master/includes/htmlform/HTMLForm.php$95

So, it looks like this will make it work properly for JS interactions as-is. I would assume and hope that this is optimized for accessibility, as if it isn't it means that any other form, anywhere else in the stack, is not a11y friendly, which is a deeper issue than this specific code.

My test environment is on the fritz at the moment, so I couldn't test it, but on its face the code looks good. I +1'ed, I need someone to do a run-through test and verify so it can be +2'ed.

I'd definitely not assume anything with HTMLForm, most of it was grown out of one perspective, one specific issue and later one possibly generalized.
Thought we have used hide-if before on a core special page, but a quick search showed only usages in Echo, GrowthExperiments and OAuth. I can't say clearly how accessible it is, everything display: none has to be carefully put on a pillow of ARIA attributes/roles for screen readers to understand normally.

@Volker_E @Prtksxna Can we file a separate task for the follow-up that needs to happen and merge @DannyS712's patch as it stands currently? I think we have delayed on this task way longer than is acceptable.

@Volker_E @Prtksxna Can we file a separate task for the follow-up that needs to happen and merge @DannyS712's patch as it stands currently? I think we have delayed on this task way longer than is acceptable.

{{ping}}

dbarratt removed a subscriber: dbarratt.Thu, Nov 19, 2:05 AM