Closed Bug 916964 Opened 6 years ago Closed 6 years ago

Improve overflow panel when lots of items are present

Categories

(Firefox :: Toolbars and Customization, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 28

People

(Reporter: Dolske, Assigned: jaws)

References

(Blocks 1 open bug)

Details

(Whiteboard: [Australis:P2][Australis:M9])

Attachments

(2 files)

Attached image 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.
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.
I think it's good to 'wait' for bug 885086 to be fixed and start fixing other overflow panel styling issues from that baseline.
Depends on: 885086
It's fixed, baseline done.

I'd say: max-height, content in a scrollbox, adjust styling a wee bit et voilà!
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 like that idea, but what'll happen when the overflow-toolbar overflows?
(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.
> 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.
Flags: needinfo?(shorlander)
Assignee: nobody → jaws
Status: NEW → ASSIGNED
<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
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
Attached patch PatchSplinter Review
Attachment #817351 - Flags: review?(gijskruitbosch+bugs)
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.
Attachment #817351 - Flags: review?(gijskruitbosch+bugs) → review+
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
Whiteboard: [Australis:P2] → [Australis:P2][Australis:M9][fixed-in-ux]
https://hg.mozilla.org/mozilla-central/rev/3f547c0bf620
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Whiteboard: [Australis:P2][Australis:M9][fixed-in-ux] → [Australis:P2][Australis:M9]
Target Milestone: --- → Firefox 28
Depends on: 1373969
You need to log in before you can comment on or make changes to this bug.