Glad thousands of users who managed to find their feature voting site pushed Mozilla to do a few baby steps
Though the current interface isn't good - mandatory group names (which also waste space in the precious tab bar by default) and inability to ungroup with a single key (due to naming conflict) - adds too much friction. Also drag&drop to group is too precise, but also can't be disable, so now you can't reliably move tabs around with a mouse without risking triggering the grouping
And, of course, one other top-10 request - to have custom keybinds to group/ungroup - is still too far from the minimum 4500 required to implement it after a few years...
It would be preferable, as a life-long user, NOT to have a "vote for your feature" website that no one really cares about, where proposal go to die. Like many petitions websites, they exist only to delude you into thinking your voice matters, or for Mozilla to delude themselves they care about what users are vocal about.
It seems to be entirely preferential. If you prefer naming tabs it's extra friction to access the input field. Options are always nice, but you will rarely cover 100% user cases on a first release.
>every square matters
If you want zero real estate, you close the tab, optionally bookmarking it.
I don't know if some 5 pixel strip really helps anyone. that sounds like functionality deferred more towards a minor extention.
Having this whole functionality is entirely preferential, so?
> If you prefer naming tabs it's extra friction to access the input field.
It's not, you can have different commands/mouse gestures for different workflows with customizable defaults to avoid most of the friction
> Options are always nice, but you will rarely cover 100% user cases on a first release.
That's a bad, though universal (can say exactly the same thing on 100th release) excuse
> If you want zero real estate, you close the tab, optionally bookmarking it.
Or close the browser. That's nonsense, why would I want absolute zero??? I want zero waste
> I don't know if some 5 pixel strip really helps anyone
Gladly there are ways to get knowledge! You can start by measuring actual width instead of making up tiny numbers. And then go on estimate the % of users who have more tabs that fit the screen width - that's the number is anyones no waste will be helping
That's why options to customize the experience is the best of both worlds. But focusing on solid defaults and then opening up with options seems to make sense.
>>That's a bad, though universal (can say exactly the same thing on 100th release) excuse
Okay. This feature had 2 updates thus far. As the kids say, "let them cook". I sure prefer an iterative release over even more delay on such a widely requested feature
> want zero waste
You need to define "waste" first. What does "zero waste" even mean in terms of UI real estate? These paradigms vary from culture to culture (e.g. Check out how utterly dense Japanese website UI is), and then person to person.
> You can start by measuring actual width instead of making up tiny numbers.
And you don't think the designers and engineers at Mozilla did this and simply interpret a different benchmark from you? I'm sure like the rest of the base UI the scaling is responsive and the size chosen balanced visual ease of perception, average user precision, and compactness.
>And then go on estimate the % of users who have more tabs that fit the screen width - that's the number is anyones no waste will be helping
Given reports in this comment section of people with 2000+ tabs and people apprehensive about more than a few tabs open, I hope you can imagine the challenge trying to accommodate such a range.
I also imagine the designers did that work already. If it fits what some quick research I did suggests, the average tab count maintained is on the lower side.
> But focusing on solid defaults and then opening up with options seems to make sense.
Since everything is entirely preferential, you can't claim the current defaults are solid
> As the kids say, "let them cook".
They had decades to cook
> I sure prefer an iterative release over even more delay on such a widely requested feature
This is just another bad excuse (and also universal), especially since the current design is more complicated (due to the extra UI element), so likely took more time to implement. Sometimes better is faster.
> You can start by measuring actual width instead of making up tiny numbers.
> And you don't think the designers and engineers at Mozilla did this and simply interpret a different benchmark from you?
How is this relevant to you making up 5px?
> challenge trying to accommodate such a range
There is no challenge here, waste becomes apparent as soon as you reach 100% width, 100 or 40k tabs doesn't matter.
> average tab count maintained is on the lower side.
You've said nothing specific here. What % of users have tabs that don't fit tab bar width? And which % counts as "anyone" from your perspective?
No friction, just proceed with what you planned on doing after making the group. The naming popup is ephemeral, it will go away if you do anything else.
Though the current interface isn't good - mandatory group names (which also waste space in the precious tab bar by default) and inability to ungroup with a single key (due to naming conflict) - adds too much friction. Also drag&drop to group is too precise, but also can't be disable, so now you can't reliably move tabs around with a mouse without risking triggering the grouping
And, of course, one other top-10 request - to have custom keybinds to group/ungroup - is still too far from the minimum 4500 required to implement it after a few years...