Page MenuHomePhabricator

Adjust the spacing of the advanced filters
Open, Needs TriagePublic

Description

With the updated icons, in beta the spacing between the advanced filters seem to have changed:

In beta with the new icons:

Screen Shot 2018-03-29 at 14.00.40 3.png (134×290 px, 5 KB)

  • Tags label is too close to the right edge.
  • The separation between the namespace and tags elements is small, making it visually unclear to which element the tag icon is associated with since both labels ("namespace" and "tags") seem at similar distances.

In production with the old icons, as a reference:

Screen Shot 2018-03-29 at 14.11.38.png (143×283 px, 5 KB)

Event Timeline

@Volker_E Did the padding on buttons / button labels somehow change as part of the icon changes?!

@Catrope The padding was slightly adapted, as the icons lost inherit, inconsistent padding (icons ranging from 13-19px width in 24x24px canvas, versus new icons following guidelines), making it – in the mid-term easier to calculate position towards design templates in CSS. Nevertheless we need to deal with some layout shifts here…

@Pginer-WMF While we're touching this, it'd be great to also address some more distance inconsistencies (inherited or changed to due icons/font-size?)

  • The ”Active filters” features computed padding of 8.4px
  • “Namespaces” & “Tags” features 0, and as “Tags” is last button in row, it doesn't receive margin to the right
  • The buttons above and below feature 12px internal padding as it's button inherit
  • And trash button has internal padding and padding of “Active filters” area

I'd want to propose two different approaches:

  1. image.png (348×2 px, 65 KB)
    with 8px unified or
  2. image.png (358×2 px, 65 KB)
    with 12px left & right, bringing also on a vertical line with buttons

I'd want to propose two different approaches:

  1. image.png (348×2 px, 65 KB)
    with 8px unified or

The intention was to use 8px as the spacing unit, so I'd go with that in general here.

For each of the advanced filters ("namespace" and "tags"), I'd increase their horizontal padding (e.g., currently the right padding/margin after the "namespaces" label is 0 ). That seems not to be affected by your examples.

@Pginer-WMF Yes, thanks. I wasn't putting this into my example, as you've already provided it in the task description. ;) For sure we'll amend white-space to align to one of my favorite gestalt principles, the law of proximity.

What if we use framed buttons instead of frameless buttons? That's what I was working on earlier today:

Screenshot from 2018-03-29 19-41-22.png (123×265 px, 3 KB)

@Catrope I found another weird behaviour when trying to access “Tags” with keyboard – I couldn't access it. Guess your take would resolve this as well?!

Change 423003 had a related patch set uploaded (by Catrope; owner: Catrope):
[mediawiki/core@master] RCFilters UI: Use framed buttons for namespaces/tags

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

@Catrope I found another weird behaviour when trying to access “Tags” with keyboard – I couldn't access it. Guess your take would resolve this as well?!

Not sure, but you can try it for yourself with the attached patch. There's also a 1px misalignment issue between the right-hand border of the Tags button and the box above it; I've seen that kind of thing before but forgot how to fix it.

Ok, the reason for the .mw-rcfilters-ui-filterTagMultiselectWidget-views-select-widget buttons being inaccessible by keyboard must have been lost somewhere in the making. ButtonSelectWidgets receive focus and are possible to be navigated with keyboard arrows.
This doesn't really make sense here, as it's not clear to the user that those two buttons are belonging to one widget.
Are there technical necessities to have it a ButtonSelectWidget or could it be two ButtonWidgets?

The misalignment of focussed buttons and widget comes from fixed height on widget without adapting buttons. As a side-note we should try not to use height and prefer min-height in order to be flexible to certain scenarios.

RHo subscribed.

Removing Wikimedia-Design as far as I can tell design is done on this and it is awaiting implementation from the relevant maintenance team (Growth)