Early on in our work defining MR1 we were faced with a decision, design two modes for our Tab experience or focus on one. At that time we made the decision to focus on designing one tab management experience that does the job well.
We heard the feedback loud and clear from the earliest iterations on vertical spacing, which shared concerns we had as a team. Since then we’ve changed and continued to refine how the base experience behaves.
So we’re going to ensure current users can retain compact mode if they already enjoy it. For other users they can find the feature behind a pref; to reveal it as an update in the density picker.
While this feature is not supported, we’ll make a SUMO article available so others can learn how to enable this feature.

For the recommended and supported experience, we encourage you to keep the normal density setting--we’ll be listening to feedback and discussions from the community, and product research as we design future iteration of this experience and other tab experiences.

(In reply to Romain Testard [:RT] from comment #0)

Early on in our work defining MR1 we were faced with a decision, design two modes for our Tab experience or focus on one. At that time we made the decision to focus on designing one tab management experience that does the job well.
We heard the feedback loud and clear from the earliest iterations on vertical spacing, which shared concerns we had as a team. Since then we’ve changed and continued to refine how the base experience behaves.
So we’re going to ensure current users can retain compact mode if they already enjoy it. For other users they can find the feature behind a pref; to reveal it as an update in the density picker.
While this feature is not supported, we’ll make a SUMO article available so others can learn how to enable this feature.

For the recommended and supported experience, we encourage you to keep the normal density setting--we’ll be listening to feedback and discussions from the community, and product research as we design future iteration of this experience and other tab experiences.

This is not a satisfactory course of action.

Either support a feature or don't. Hiding even the possibility of a user choosing Compact Mode is the first step to full deprecating the feature.

I can assume that once actual data was gathered on Compact Mode that it was found a significant number of users were taking advantage of the feature. In this case Users want the feature. What is gained by hiding the compact mode option. It is an option in a list with Normal and Touch Density so it takes no extra space in the UI. Hiding it by default feels like a punative and frankly childish action by desingers who have been forced to rethink their ideas due to user feedback.

Please explain the rationale for removing Compact Mode from the Density list.

And in light of developers considering Touch Density an accessibility feature will the Density List be given more prominence in future versions of Firefox?

Thanks for trying to listen to the feedback! However, I don't think this will work either.

People who are already using compact mode will keep the entry, which is nice. However, compact mode in Proton/MR1 uses almost the same space as Quantum in normal mode. So these people won't be happy, otherwise they would be using Quantum in normal mode which is the default.

And then there are people like me, who are perfectly happy with normal mode in Quantum, but who will want the compact mode in Proton/MR1, since normal Proton/MR1 wastes too much space, even after bug 1698244.
By the time we get updated to a version which has Proton/MR1 enabled by default, this bug will have hidden the compact mode entry.
So, as I said in bug 1693028 comment 10, I ask you to keep the compact mode entry for at least 1 release after shipping Proton/MR1, in order to let people switch to it. Remove it afterwards if you feel so.

https://hg.mozilla.org/mozilla-central/rev/7786ba3e301e

Could you please clarify whether I understand correctly that, while the compact density is not being removed, it's going to the same "semi-supported" state that userChrome.css is in? As in "the option is still technically there, but it's not officially supported, it can be slower / worse integrated, and when (not if) it breaks, you get to keep both pieces"?

What is the link for the SUMO article? I searched for "compact mode" on https://support.mozilla.org/en-US/#search (with and without quotes) and the article didn't appear in the first few pages. Searching for "compact" in the help articles only had five hits and none of them were about Compact Mode.

(In reply to B.J. Herbison from comment #9)

What is the link for the SUMO article? I searched for "compact mode" on https://support.mozilla.org/en-US/#search (with and without quotes) and the article didn't appear in the first few pages. Searching for "compact" in the help articles only had five hits and none of them were about Compact Mode.

This will be addressed with bug 1703785

Is it just me or this is overly complicating things?

By hiding it in about:config the following are needed:

• preference settings
• handling density menu based on said preference
• a help article
• design implementation
• calming angry users

Whereas for just keeping it in menu entry:

• design implementation

I don't understand this decision. First the removal of compact mode was motivated because is has bad discoverability. Then community raise its voice to say that not what it wants. And the answer is to make the setting even less discoverable…

Of course is won't be used if it is less and less discoverable. And this decision break the meaning of doing telemetry on compact mode altogether, how are we going to mesure if people prefer Proton normal vs Proton compact if they don't even have the option showed at all???

Please keep support on compact mode, don't let it rot and broke

(In reply to Geobert Quach from comment #14)

I don't understand this decision. First the removal of compact mode was motivated because is has bad discoverability. Then community raise its voice to say that not what it wants. And the answer is to make the setting even less discoverable…

Of course is won't be used if it is less and less discoverable. And this decision break the meaning of doing telemetry on compact mode altogether, how are we going to mesure if people prefer Proton normal vs Proton compact if they don't even have the option showed at all???

Please keep support on compact mode, don't let it rot and broke

This is my question exactly. For someone that deals with many tabs due to research and design using web apps the lack of compact mode is a UI mess...it is part-way to the microsoft office ribbon design which I have not found more efficient even after over a decade of use.

What is informing this decision to remove compact mode? If it is analytics, you should be weary of letting analytics inform design decisions (as is the industry standard) as it skews the reality of what people really want based on usage limited by existing designs. (such as having compact mode being relatively hidden and therefore not used as much). If it is user feedback, are you sampling random users or are you including power users which have been a critical part of your user base for decades.

omg thank you so much.

Thanks !

I find Compact mode very usefull on a laptop !

Even on a 15" screen, it saves a lot of space when you need to work and produce something on a rich web-ased application. (like Google Docs, diagrams, etc.)

Context: (quoting bug #1693028 )
With the Proton redesign (refresh of the Firefox UI), we have to make difficult scope decisions to ensure Firefox remains simple to use and simple to maintain. The "Compact" density is a feature of the "Customize toolbar" view which is currently fairly hard to discover, and we assume gets low engagement

I agree with the fact thats the "Customize toolbar" feature probably gets low engagement.
This sounds a little bit 1990's for me ;) and is probably - I'm a (web) developper - a real labyrinth to maintain.

But giving the ability to choose a display density is still great, and maybe should be made a little more easier to find.

Regards,
Jim