1703254 - Maintain compact mode for current users and move to about:config preference

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect)

Description

[Romain Testard [:RT]]

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.

Comment 2

[Blake Winton (:bwinton) (:☕️)]

Attachment: Bug 1703254 - Hide compact mode for people who don't use it, and Density menu when there's only one option. r=Gijs

Comment 3

[rghtbrn]

(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?

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7786ba3e301e
Hide compact mode for people who don't use it, and Density menu when there's only one option. r=Gijs,fluent-reviewers,flod

Comment 5

[Oriol Brufau [:Oriol]]

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.

Comment 6

[kellegram]

Completely agreed, there needs to be compact mode that actually compacts the bar in a noticable way, as there is far too much vertical space being wasted. We already seen how good 3:2 monitors are thanks to the taller aspect ratio. People clearly love it and while sadly it's not easy to fight through the dominance of 16:9, those who do get to use more vertical space struggle to go back. Why have an extra thick bar that serves little purpose when that could give me more content to view at any given moment. I would be fine with having to use about:config for it even, I would just add it to my user.js, but I really hope it both remains an option and actually looks compact.

Comment 7

[Bogdan Tara[:bogdan_tara | bogdant]]

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

Comment 8

[Denis Lisov]

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"?

Comment 9

[B.J. Herbison]

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.

Comment 10

[Romain Testard [:RT]]

(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

Comment 11

[nanaya]

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

Comment 12

[DannyS]

(In reply to rghtbrn from comment #3)

(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?

The logic is quite clear to me:

1. Actual telemetry data is likely indicating that many users use Compact Mode, but there is a strong push from some senior team leads to get rid of it.
2. Hide the option in a convoluted manner.
3. Run another telemetry collection exercise in, say, 1-2 months.
4. The number of Compact Mode selections will have declined, either because new users weren't presented with this option or for various other reasons (new profile creations, browser resets, computer reinstall). The happy conclusion is now that that Compact Mode is - obviously - on its way out, and we now have the new telemetry data to prove it.
5. Quickly push a deprecation of the feature in the next version, and WONTFIX any bug filed by annoyed users.
6. Problem solved.

Comment 13

[Shrey]

I am not updating Firefox ever if compact mode is removed or Hidden in about:config.

Comments from community and Firefox/Mozilla about removing/hiding the compact mode indicates that even before knowing/sharing the telemetry about compact mode usage they(Firefox/Mozilla) want to remove it so that they have to maintain less. So why not make the Compact mode the default mode and put the touch or normal density in the about:config? This way Team will only have to maintain one mode and all the users will happily use Firefox.

At the end i request you to please dont make this a ESNI/ECH situation where Firefox implemented ECH and deprecated ESNI even when there was and still is no support for ECH.

Comment 14

[Geobert Quach]

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

Comment 15

[Leo_sk]

It would be my request to firefox developers and product management to not alienate the more tech-literate users in attempt to make firefox more appealing to less tech-savvy masses. These are the same users who recommend firefox to their peers and bring in free advertisement for firefox, which is one area where mozilla has not invested much and I suspect is not in condition to do so. Chances that an average internet user encounters firefox and then goes about to learn about it is fairly minimal. The most common reason that most users stick with firefox is because it is the only major browser with copy-left licence, and is free from control of any major for-profit company, but there is a limit until which this ideal can stand. Had userChrome.css not been a thing, many users would have abandoned firefox after the megabar debacle (including me). From experience, i do realise that this decision on toolbar thickness is not going to be undone, but gradually removing features that appeased the more tech-savvy crowd is going to harm firefox usage in the long run. Unless the intention is to kill firefox by justifying its small userbase in future, I can not see how it is a preferred course of action.

And to make it easy for moderators, you can hide the comment citing advocacy

Comment 16

[Patrick Storz]

At that time we made the decision to focus on designing one tab management experience that does the job well.

This is the fundamental misconception about it - it does not do the job well!

Just saw the "updated" design in Firefox Developer Edition and wanted to cry.

Went to the settings intending to activate compact mode in hopes of it improving things and started screaming!

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.

Really? Where? For me it is absolutely unclear who's listening to the community and where they are listening. Design gradually becomes worse, but somehow you always claim to have based it on user feedback. Yet I've not been asked a single time for my opinion and I've been using and contributing to Firefox for years. Maybe you're asking the wrong people?

Comment 17

[Christopher]

(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.

Comment 18

[Leo_sk]

(In reply to Christopher from comment #17)

What is informing this decision to remove compact mode?

Its management's whims and fancies

Comment 19

[jrgochan]

omg thank you so much.

Comment 20

[Jim Etevenard]

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

Comment 21

[Will]

Important development about this subject: Chrome seems to have gotten enough complaints about their UI refresh that shipped in late 2023 that they've decided to make an optional "compact" mode https://x.com/Leopeva64/status/1816605941686579626

I understand that designing and testing/maintaining 2 or 3 different UI densities is extra time and work but it's clear that we can't ignore or dismiss the large amount of users unhappy with these large touch UI's. And if Chrome is shipping a compact mode, just from a product parity perspective Firefox should also have an officially supported compact density.

Also worth noting that a lot of Firefox users don't even have a touchscreen, and even if they do have one, a large amount of users don't or rarely use the touchscreen! So only shipping a large touch UI to Firefox users wasn't a good decision. MacOS has no touchscreen support, for example.