<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 10/5/2017 8:34 AM, Chris
Hutten-Czapski wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMPhgK_G3tYYwygeNJYfbp_UqK4wvLnDEx-A9TLdZA4x-O6=bg@mail.gmail.com">
<div dir="ltr">
<div>I prefer the old behaviour, but I don't have a strong
opinion on the matter. I think it's because I'm used to tab
navigation by keyboard shortcut more than by mouse. I
rearrange tabs so that they're close together.<br>
</div>
<div><br>
</div>
<div>For everyone curious about how much of an outlier your
subsessions are... on Nightly 58: <a
href="https://mzl.la/2ge6Bpk" moz-do-not-send="true">https://mzl.la/2ge6Bpk</a></div>
<div>Over 20% of subsessions have only one tab.</div>
<div>50% of subsessions have 3 or fewer</div>
<div>Over 90% of subsessions have 20 or fewer.</div>
<div>99% of subsessions have 218 or fewer tabs open
concurrently.</div>
<div><br>
</div>
<div>Of course this is wildly different on other[1] channels: (</div>
<div>Beta 57's 99%ile is at 22[1]</div>
<div>Release 56's 99%ile is at 148, with 94% of subsessions with
20 or fewer tabs[2]</div>
<div><br>
</div>
Note: <a href="http://telemetry.mozilla.org"
moz-do-not-send="true">telemetry.mozilla.org</a> is
per-subsession aggregation, not per-client, so clients with more
subsessions are weighted more heavily (pseudoreplication). Just
something to keep in mind.<br>
<div>
<div><br>
</div>
<div>:chutten<br>
</div>
<div><br>
</div>
<div>[1]: <a href="https://mzl.la/2gdB1YP"
moz-do-not-send="true">https://mzl.la/2gdB1YP</a></div>
<div>[2]: <a href="https://mzl.la/2gdXftM"
moz-do-not-send="true">https://mzl.la/2gdXftM</a><br>
</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<br>
<br>
That telemetry data is max tabs across all windows, which doesn't
really match up with the needed understanding for this change. Is
there telemetry data for max tabs for individual windows?<br>
<br>
Looking at the available space on a 1080p monitor with maximized
window, 50px, 75px, and 100px should allow a max of around 35, 24,
and 17 tabs, respectively, before scrolling begins.<br>
<br>
For a lower resolution, or non-maximized windows, perhaps a 20%
reduction to something like 28, 19, and 14 tabs.<br>
<br>
Caveat: OP said that he gets scrolling starting at 12 tabs, which
suggests a window size of perhaps 2/3 the screen width. That
increases the value of reduced minimum tab width, but does not
improve the situation of tab usability relative to telemetry data,
as seen below.<br>
<br>
For the purpose of not needing a second window, 75px would cover the
93% to 95% range on the Release channel. 100px would be 91% to
93%. 50px would be 95% to 96%.<br>
<br>
The thing is, while that covers the raw number of tabs used, how
many people start creating new windows prior to that just so that
the tab titles can be legible? Making is so that you *can* shrink
it further is fine, but to what degree would it actually be
*helpful*?<br>
<br>
Telemetry data for window counts puts 1 window at 79%, 2 windows at
93%, and 3 windows at 97%.<br>
<br>
Tab counts at those tiers are 6 at 80%, 16 at 93%, and 42 at 97%.
If distributed evenly, that's 6, 8, and 14 per window, which is
below the threshold of even the 100px tab size. Similarly for the
Nightly 95th percentile, with 3 windows and 36 tabs, suggesting 12
tabs per window.<br>
<br>
That implies that even though people can already fit more tabs per
window without scrolling, they aren't actually doing so.<br>
<br>
Moving up the scale some, the 99.1% rate corresponds to 5 windows
and 160 tabs, for 32 tabs per window. This suggests that the lower
minimum tab size *might* be useful. But we're also approaching the
territory where tab management is a significant aspect of using the
browser, which means that the usage of an extension like Tab Groups
starts rising exponentially. <br>
<br>
Thus we can't actually be sure that minimum tab size is relevant,
even with this many tabs in one window. I myself have a window with
63 tabs in it, but with Tab Groups, the most that are visible at one
time is only 9.<br>
<br>
It would seem that the overall purpose of shrinking the minimum tab
size is as a stopgap tab management tool to make up for weakening
tab management options elsewhere. Ironically, the dropdown list for
tabs once the scrolling appears is actually *more* useful for
finding the tab you want as the tab size shrinks, so reducing the
minimum tab size actually makes it more difficult to use that
approach.<br>
<br>
In any case, it makes it not very useful to use the Release channel
telemetry for the purposes of examining this, because factors that
influence tab/window counts are being removed. So reviewing again
using just the Nightly telemetry.<br>
<br>
1 window = 78% = 9 tabs = 9 tabs per window<br>
2 windows = 93% = 26 tabs = 13 tabs per window<br>
3 windows = 97% = 67 tabs = 22 tabs per window<br>
4 windows = 98% = 137 tabs = 34 tabs per window<br>
5 windows = 99% = 236 tabs = 47 tabs per window<br>
10 windows = 99.77% = 704 tabs = 70 tabs per window<br>
<br>
It's interesting that tabs scale up more rapidly than windows. But
I suppose 10 windows with 70 tabs each is far more usable than 70
windows with 10 tabs each. This is again a scenario where something
like Tab Groups would be ideal, because it takes the pressure off of
window management.<br>
<br>
Regardless, as the tab count per window goes up, the degree to which
the minimum tab size is relevant goes down. Even with 50px tabs,
you're far past the point of needing a scroll bar by the time you
hit the 99th percentile. That suggests that the users are very
likely to be using alternative mechanisms such as the dropdown tab
list, or various extensions.<br>
<br>
Putting it all together, this implies that changing the minimum tab
size is only useful within a very specific range. Going below 100px
minimum size is unlikely to be relevant until you're going over
several dozen tabs in just a few windows (3). Going down to 50px
minimum size is not particularly useful once you're into the
hundreds of tabs in a few windows (4).<br>
<br>
That means that reducing the tab size only helps users between the
97th percentile and the 98th percentile.<br>
<br>
Now, having it customizable is fine, as various users like to tweak
things for their own comfort. However, looking at the numbers
suggested by the telemetry, I do not see any convincing evidence
that changing the *default* value will be of much use.<br>
<br>
At best, I'd suggest a minimum tab width scaled relative to the
browser vs screen width. Assuming a 1920x1080 resolution, having a
100px min width when the window is maximized, vs a 50px min width
when the browser window is half the screen width or less. That
would make the number of visible tabs consistent as the window size
changes. You could then either choose the proportional method, or a
fixed value.<br>
<br>
--<br>
David<br>
<br>
<br>
<br>
</body>
</html>