916964 - Improve overflow panel when lots of items are present

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[Justin Dolske [:Dolske]]

Attachment: Screenshot

The overflow panel doesn't really have a great UX when there are lots of items present; it's just a long single column.  It works pretty well for the common case (just a few extra buttons), but starts to fall over if a user adds more and more, or if when we migrate users who had a addon-bar chock full of buttons.

We should take a look at possibilities for improving it in such cases. Perhaps we can steal some code from the menu panel, and have it use multiple columns once it's X items tall? Or somehow switch to smaller icons for a more dense listing?

Possible we'll do nothing, but setting P2 to take another look and decide.

Comment 1

[Dão Gottwald [:dao]]

Also relevant for the layout of this panel: Why do buttons get their labels rendered when overflowing but not when they fit on the toolbar? I can't think of a reason why this different treatment would make sense.

Comment 2

[Mike de Boer [:mikedeboer]]

I think it's good to 'wait' for bug 885086 to be fixed and start fixing other overflow panel styling issues from that baseline.

Comment 3

[Mike de Boer [:mikedeboer]]

It's fixed, baseline done.

I'd say: max-height, content in a scrollbox, adjust styling a wee bit et voilà!

Comment 4

[Justin Dolske [:Dolske]]

An idea I suggested on IRC a couple days ago:

Instead of a vertical overflow panel, use a horizontal toolbar that slides down. Clicking the overflow button (») would show/hide it (as it does with the panel today, basically).

This solves a few issues:

* Can handle more icon than overflow panel does (ie, fixes this bug), so upgrading users who have been making heavy use of the add-on bar (or who just want to install lots of addons) have a better experience.

* Can be shown intuitively in customization mode, so that you can see and rearrange them. (Overflow would, my thinking goes, still be automatic. So you can change the order, but the browser would still place items in the navbar or overflowbar based on space and order.)

* Arrow panels and menus associated with the button (eg, Downloads) can anchor directly to the button when clicked, instead of the overflow button.

* Styling bugs (as happen to be shown in the screenshot here) would presumably be less common, since buttons would simply be on a different toolbar.

* Wide widgets (like a search box) don't need special treatment.

* Offers a middle-ground for users who really really love their addon bar.


The one downside I can think of is that, as with the old addon-bar, when just a few buttons end up there you get a big mostly-empty widget. But I think that's not a dealbreaker, because it only happens upon overflow, and is now secondary UI (ie, behind a click-to-show button). We will still have fixed the "install one addon, get a useless toolbar with a tiny button" problem.

Comment 5

[Mike de Boer [:mikedeboer]]

I like that idea, but what'll happen when the overflow-toolbar overflows?

Comment 6

[Dão Gottwald [:dao]]

(In reply to Mike de Boer [:mikedeboer] from comment #5)
> I like that idea, but what'll happen when the overflow-toolbar overflows?

It could wrap or we could decide not to care about that case since the add-on bar didn't support it either.

Comment 7

[Mike Conley (:mconley) (:⚙️)]

> An idea I suggested on IRC a couple days ago:
> 
> Instead of a vertical overflow panel, use a horizontal toolbar that slides
> down. Clicking the overflow button (») would show/hide it (as it does with
> the panel today, basically).
> 
> This solves a few issues:
> 
> * Can handle more icon than overflow panel does (ie, fixes this bug), so
> upgrading users who have been making heavy use of the add-on bar (or who
> just want to install lots of addons) have a better experience.
> 
> * Can be shown intuitively in customization mode, so that you can see and
> rearrange them. (Overflow would, my thinking goes, still be automatic. So
> you can change the order, but the browser would still place items in the
> navbar or overflowbar based on space and order.)
> 
> * Arrow panels and menus associated with the button (eg, Downloads) can
> anchor directly to the button when clicked, instead of the overflow button.
> 
> * Styling bugs (as happen to be shown in the screenshot here) would
> presumably be less common, since buttons would simply be on a different
> toolbar.
> 
> * Wide widgets (like a search box) don't need special treatment.
> 
> * Offers a middle-ground for users who really really love their addon bar.
> 
> 
> The one downside I can think of is that, as with the old addon-bar, when
> just a few buttons end up there you get a big mostly-empty widget. But I
> think that's not a dealbreaker, because it only happens upon overflow, and
> is now secondary UI (ie, behind a click-to-show button). We will still have
> fixed the "install one addon, get a useless toolbar with a tiny button"
> problem.

I actually quite like the idea, personally. I think it would certainly simplify some of our CSS.

Needinfo'ing shorlander to get his position.

Comment 8

[Jared Wein [:jaws] (please needinfo? me)]

<shorlander> jaws: make the overflow container a toolbar?
<shorlander> Please don't do that
<jaws> shorlander: if we do this, do you think the overflow toolbar should remember if it was open and reopen if items overflow
<shorlander> jaws: No, my point was I don't think we should do this at all
<jaws> oh, i missed shorlander's "Please don't do that"
<shorlander> jaws: I don't think this is a direction we should pursue.
<jaws> shorlander: how do you think we should handle lots of items in the overflow panel? just put a scrollbar on there?
<shorlander> jaws: if it comes to that, yes

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

From IRC:

<jaws> shorlander: i think dolske makes some good points in https://bugzilla.mozilla.org/show_bug.cgi?id=916964#c4
<shorlander> jaws: It can't handle more overflow than the panel because the panel can scroll, it will create a direct disconnect between the button you click and the UI element shown (i.e. click on far right get item on far left), will create yet another UI element which is something we don't want, in likely the vast majority of cases it will create a full window width toolbar with one or perhaps two items on it, it's just weird and doesn't conform with most system handling of overflow, but most it is an inelegant solution catering to a case which we don't want to encourage anyway

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch

Comment 11

[:Gijs (he/him)]

Comment on attachment 817351 [details] [diff] [review]
Patch

Review of attachment 817351 [details] [diff] [review]:
-----------------------------------------------------------------

r=me

::: browser/themes/shared/customizableui/panelUIOverlay.inc.css
@@ +424,5 @@
> +  max-height: 30em;
> +  overflow-y: auto;
> +  overflow-x: hidden;
> +  margin-top: 10px;
> +  margin-bottom: 10px;

I am a margin: 10px 0; kind of guy, but either works, as far as I'm concerned.

@@ +430,5 @@
> +
> +#widget-overflow-list {
> +  width: @menuPanelWidth@;
> +  padding-left: 10px;
> +  padding-right: 10px;

And therefore also padding: 0 10px. Again, not fussed whether you leave it or take this aboard.

Comment 12

[Jared Wein [:jaws] (please needinfo? me)]

Thanks for the quick review. I'd rather only set the properties that needed changing, and leave alone ones that aren't in need.

https://hg.mozilla.org/projects/ux/rev/3f547c0bf620

Comment 13

[:Gijs (he/him)]

https://hg.mozilla.org/mozilla-central/rev/3f547c0bf620