New scope selector is confusing and unattractive

[ssokolow]

At the moment, my primary browser is still Firefox 52 ESR, while I investigate the best options for replacing addons that are impossible to implement under WebExtensions restrictions. This is the scope selector from uMatrix which I am used to seeing in those conditions:

While it doesn't technically have any indication that it's a dropdown list widget (eg. ▼), the on-hover "this is interactible" highlight it provides is consistent with the rest of the UI and it looks clean and reasonable.

(It also fits neatly into the implicit four-section grid formed by a table with both row and column headers, being only as wide as the row headers and only as tall as the column headers.)

When I started building a Firefox 58 profile for comparison against options such as Waterfox, this is the interface that I was greeted with by the current uMatrix release:

It has the following flaws:

• Even now, I still can't help but perceive it as a rendering glitch and it makes me cringe. This is for two reasons:
  • The domain is clearly drawn as a single span of text, rather than being part of two separate widgets.
  • There is a thin blue border around the disabled button, which makes it look like a gray artifact within a blue widget, rather than a deactivated segment in a row of three. (We intuitively expect the active/highlight color to be the one that has a smaller bounding rectangle, if one of the states doesn't fill all the way to the edge.)
• It took me a surprising amount of time to understand what I was actually perceiving when I first tried interacting with it to see if I could get the extension to redraw the panel so the glitch would go away.
• It bears little visual resemblance to any standard GUI widget, which harms its intuitiveness.
• Being "within the toolbar" visually, the * button looks like a badly-styled disabled toolbar button, rather than part of the scope selector.

Here are my suggested options for resolving this intuitiveness/consistency regression, with mockups:

• Narrow it down so the * is within the column delineated by the row headers, then restyle the domain name so it looks more like a split-button and less like a drawing glitch overlaid on some text. (The main issue there being the lack of familiar "this is a button" cues, combined with the clear and obvious detail that the domain name was rendered as a single span of text, rather than divided between two interactible widgets.)

  

  

• Just go back to the old way... possibly adding a ▼ to the end as a cue that it's a dropdown widget. (Drop-down widgets are a tried and tested GUI element that people are familiar with and a ▼ as a cue would resolve any perceived intuitiveness shortcomings.)

  

Personally, I'd just go back to the dropdown. The current approach feels like a solution that's too clever for its own good and the old approach maximized the amount of usable space by not having a permanently visible * button and not needing to deal with having the buttons look like a rendering glitch if there's no space and/or border between the subdomain and domain portions.

[theWalkingDuck]

The click to select or to deselect the scope is fully in the spirit of uMatrix as the click to allow or to block a content.

I have a problem with the idea to bring back that clunky dropdown menu again.

[ssokolow]

I'm not really sure there's any definition of "in the spirit of uMatrix" which is meaningful enough to overrule other UI concerns, given that the scope selector has characteristics that set it apart from all other widgets in the dialog:

• Unlike the allow/deny cells, it is a hide/show operation, rather than a set/unset operation.
• Unlike the buttons for expanding/collapsing blocks of rows, it has more than one possible value.
• Unlike any of the other widgets, it's effectively a means for selecting a two-dimensional slice of a three-dimensional data space.

I have a problem with the idea to bring back that clunky dropdown menu again.

In what way do you find it clunky? I don't find myself flipping back and forth between scopes often enough to make it bothersome, so it's possible I'm overlooking something.

That said, I do think there will always be a certain learning curve to the new design, simply because the flat style used by uMatrix makes it difficult to communicate something like "this is a group of toggle buttons" (example) or "this is a breadcrumb widget" (example) or some other intuitive signal which would help people to quickly grasp how the widget should behave based on prior experience.

[gorhill]

In what way do you find it clunky?

Requires more than one click to change scope, and make scoping less prominent -- which is a core concept in uMatrix. I've seen so many "I can't create a rule which applies everywhere", and making the global scope in full view ready to be used is bound to help with this. Actually, I should add a tooltip to the global scope button to explicitly state its purpose.

[ssokolow]

and make scoping less prominent -- which is a core concept in uMatrix. I've seen so many "I can't create a rule which applies everywhere", and making the global scope in full view ready to be used is bound to help

Fair enough. While the addition of a ▼ would definitely have helped there, the new design does mean that people will actually think to check for a tooltip. (On the other hand, with the dropdown, the * could have been replaced with something like "Default Behaviour" or "All Sites")

Actually, I should add a tooltip to the global scope button to explicitly state its purpose.

Definitely. Any button or label which contains only a single glyph should have one.

(Speaking of which, the ⋮ button should also have a tooltip which makes it clear that the settings contained within are scope-specific. That's one thing that I misunderstood when I first started using uMatrix because it felt like they were too "distanced" from the scope selector for it to modify their effects... similar to how I wouldn't expect the scope selector to control output filtering in the logger window.)

[mikhaelkh]

@ssokolow all blue buttons are scope-specific, all black buttons are not. While I think that while the UI isn't perfect, the scope selector change was definitely good, you're just used to dropdown list, after a while this makes perfect sense. My two cents:

• Revert all temporary changes button isn't grayed out when there're no temporary changes like Revert temporary changes for this scope.

• If a cell has a permanent rule assigned to it and you change the state of the cell, you will see that the permanent state and the temporary state become different as a result.

  Why add "If a cell has a permanent rule assigned to it" condition? Isn't the approach to always show permanent state of the cell in the corner better, including indication that there's no permanent rule?

[ssokolow]

all blue buttons are scope-specific, all black buttons are not

Even knowing that those two buttons are scope-specific, I either didn't notice that they were blue or didn't register it as significant until you called my attention to it.

I suspect it's a cognitive artifact akin to banner blindness that has to do with that shade of blue either being or closely resembling the default hyperlink colour. (ie. Subconsciously dismissing the blueness of the toolbar buttons as an irrelevant detail caused by a CSS bug based on prior experience with clickable things sometimes being blue and sometimes not.)

Either way, the "something this many steps removed from the selector" (in a menu within a toolbar button) intuition overwhelms the "blue things are scope specific" intuition for reasons similar to my not expecting the scope selector to control filtering on the logging window. Hence my point that it needs that clarified in a tooltip.

Actually, now that I think about it, the fact that it's a dropdown might be part of the reason my intuition dismissed the blue as a bug... because the "display a submenu" that happens when you click on ⋮ is a hide/show action with no effect on the data model rather than a toggle with persistent effects and, therefore, the hypothesis that blue means "affected by the state selector" is disproved because it appears on something with no state to be affected. (Which would then be reinforced by the contents of the dropdown being black rather than blue.)

[gorhill]

Current scope selector is by-design, I do not intend to change it.

[ssokolow]

What about the most minor tweak in option B?

(Remove the line of blue surrounding the grey and add a couple of pixels of padding and a border between each independently clickable segment (ie. bugzilla., mozilla., and org) to make it clear that it's a row of buttons, rather than a rendering glitch drawn under the left end of a single text widget.)

[gorhill]

The blue border is by-design, it's to visually convey that the current selection is a subset of all fields available inside the whole button (whole = blue border).

[ssokolow]

Well, with the lack of padding between the bugzilla. and the mozilla.org, I interpreted it as a rendering glitch drawn behind a single text widget.

(Plus, what you're doing is the flat-design equivalent of putting buttons within buttons in a native GUI toolkit like Qt or GTK+... and that's discouraged by design specialists.)

EDITED BELOW

For now, I'll use the following in my userContent.css:

/* Fix rendering glitch-esque default style in uMatrix scope selector */
@-moz-document url-prefix("moz-extension://19c6955d-eec7-44a2-a3da-c58f4daa2329/") {
    body .toolbar #specificScope {
      padding: 0 !important;
      border: 0 !important;
    }

    body .toolbar #specificScope > span {
      padding-right: 3px !important;
      padding-left: 3px !important;
      border-left: 1px dotted #77f !important;
    }

    body .toolbar #specificScope > span:first-of-type {
      border-left: none !important;
    }

    /* ...and fix text contrast on deselected scope buttons for readability */
    body .toolbar .scope:not(.on),
    body .toolbar #specificScope > span:not(.on) {
        background-color: #aaa !important;
        border-color: #aaa !important;
    }
}