Page MenuHomePhabricator

Special:AbuseFilter: OOUI widgets take up more vertical space
Closed, ResolvedPublic

Description

I was reviewing https://gerrit.wikimedia.org/r/#/c/418716/ for T132284: Convert Special:AbuseFilter to OOUI and noticed that the OOUI version of the form takes much more space. Here is before:

And after converting to OOUI:

Emphasizing on the fact that the form is twice as tall with lots of extra white space.

We need a way to do the following:

  1. Make the label for the radio buttons appear on the same line as the radio buttons. Same with the checkbox.
  2. Make the dropdown not only appear on the same line as the label, but also not be this wide when its options are short strings (20, 50, 100, 250 and 500 are the options).

Looking at https://doc.wikimedia.org/oojs-ui/master/js/#!/api/OO.ui.LabelWidget I cannot find a way to specify a label as "inline". I see some mention of inline for FieldLayout but am not sure how that would apply here. I also don't see any options to control the size (width) of a SelectWidget

Not only would it be great to have the option to control this on a per-widget basis (and if there is the option, please point me to it), but also I think there should be a general option to use for an entire OOUI form to make it "compact", which would automatically be judicious in using extra lines and white spaces.

Event Timeline

Huji created this task.Mar 11 2018, 7:44 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 11 2018, 7:44 PM
Huji updated the task description. (Show Details)Mar 11 2018, 7:45 PM

Emphasizing on the fact that the form is twice as tall with lots of extra white space.

Does this create an actual specific problem when you're using the page (how?), or is that more of a "I don't like it"?

Huji added a comment.EditedMar 12 2018, 2:35 PM

It does, from a usability stand point. With the new (OOUI) layout, and especially once more search fields are added to this form (see T87455), you won't see the list of filters without scrolling once or twice on most monitors and devices.

I am sure you agree that "usability problems" are real problems. If not, we could always practice WP:POINT and make every single MediaWiki form two or three times taller, until usability problems are universally apprecaited ;) Just kidding of course.

Daimona removed a subscriber: Daimona.
Daimona added a subscriber: Daimona.
Volker_E renamed this task from OOUI widgets take a lot of space to Special:AbuseFilter: OOUI widgets take up more vertical space.Mar 17 2018, 5:51 AM

The alignment of labels top and inputs bottom is coming from user experience studies showing that users orient better and resolve forms more quickly with this layout.

Apart from that we also took focus on providing a mobile-friendly approach to our UI design by ensuring minimum touch targets (>=40px) on elements like buttons or checkboxes. There are quite some things possible to be optimized on, but right-left aligning is not resulting in a useful outcome IMHO.

My proposals:
We could add a special CSS file for this view with either “Options” or even more preferably “Deleted filters” and “Disabled filters” label with .mixin-screen-reader-text() visually hidden as they are both self-explained in the checkbox and radio labels.

Jfyi: There's also currently T97631 going on, which will have a positive, slightly shrinking impact on Special:Pages' OOUI appearance

@Volker_E I understand that OOUI has studies behind which determined how to handle certain things like the size of elements. In fact, I think that for the moment we may still convert the AbuseFilter form and keep it bigger, to be compliant with other uses of OOUI all around the software. However, there's at least one specific case for which we'd really need a smaller input, which I exposed in T132284#4057385. That field will take a number with less than 4 digits, and it would be a real exaggeration to use a page-wide field for that. Is there a smaller alternative for this case, or do we need some CSS hack?

This comment was removed by Xaosflux.

@Aklapper, yes requires scrolling to even see the widget controls at many resolutions or if any project specific help as been customized in the summary area.

Xaosflux added a comment.EditedApr 25 2018, 1:29 PM

Here is a full screen example of the new layout, at 1050x1680 resolution - the menu selector consumes the majority of the screen now.

Volker_E added a comment.EditedMay 20 2018, 3:58 AM

The distance in “Disabled filters” originates in a wrong field initiation, those are two disconnected fields, where it should be one. @Daimona could you look into this?
I've provided a patch for T181770 that should balance the other form fields' whitespace/distance in Monobook here more appropriately as well.

@Volker_E Sure. However, I'm not sure how to change it. Currently, we have info+check fields because we use two different labels for the checkbox. Some solutions I can think of are:

  1. Change the deleted filters headers from "Deleted filters:" to "Deleted and disabled filters" and move there the checkbox on a new line.
  2. Put the checkbox on the same line as its header label.
  3. Rework this section like the one for deleted filters, so to have 3 radios instead of one checkbox.

Of course, it might be even better to compact info and check in a single field, but I couldn't find a way to add such a double label.

@Daimona: Hmm, an aligned=top FieldLayout wouldn't work?

Daimona added a comment.EditedMay 30 2018, 7:36 PM

@Volker_E It could, but we're using HTMLForm there (code) and I couldn't find an appropriate field type for that. Is there one?

If a solution is available, we'll also have to apply it to this.

The ”Number per page” dropdown width can be overriden in per page CSS. You could either go for a short em width similar to what we do in the demo views dropdown (there 10em) or if the default label is the longest auto would work. But it has it's shortcomings if there is one of the shorter values the default (clipping longer dropdown menu items as result).

Change 439880 had a related patch set uploaded (by Daimona Eaytoy; owner: Daimona Eaytoy):
[mediawiki/extensions/AbuseFilter@master] Reduce form whitespace on Special:AbuseFilter and compact variables

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

Daimona claimed this task.Jun 12 2018, 11:32 AM

@Daimona Would you provide before/after screenshots here for documentation purposes?

@Volker_E Sure! Sorry for the missing i18n, but I don't think it's a problem.
Before:


After:

Change 439880 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] Reduce form whitespace on Special:AbuseFilter and compact variables

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

Huji added a comment.Jun 26 2018, 2:16 AM

@Daimona should we close this task?

Daimona closed this task as Resolved.Jun 26 2018, 9:23 AM

@Huji Well, that's a good point. There are several factors to take into account: first, it won't be possible for us to reduce taken space too much, so we'll need to be happy with it sooner or later. Also, we don't want to over-reduce it, since a broader form is easier to understand and fill. IMHO the current form is acceptable in height, is easy to read and I can't see any waste in used space, so I'm closing this task. However, there may be situations (probably skin-dependant) where the taken space won't be acceptable. If a situation like that is reported, then I'll be happy to work on it again.