Closed Bug 1693028 Opened 1 year ago Closed 1 year ago

Remove compact mode inside Density menu of customize palette

Categories

(Firefox :: Toolbars and Customization, task, P3)

task
Points:
3

Tracking

()

RESOLVED DUPLICATE of bug 1703254

People

(Reporter: RT, Assigned: bwinton)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

(Whiteboard: [proton-foundations])

User Story

Context:
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. We want to make sure that we design defaults that suit most users and we'll be retiring the compact mode for this reason.

Here are details from the hardware report on Firefox display resolutions (https://data.firefox.com/dashboard/hardware):
- 31.7% of users run 768 pixels height (decrease over time)
- 61.6% of users run more than 768 pixels height (increase over time)
- 6.7% of "Other" (headless, rare resolutions, ...)

We decided to focus on 768 pixels as the minimum height we want to optimize for and the new Proton tabs and address bars account for 92 pixels height, therefore leaving 88% of screen height available for the users in our worst case scenario of 768 pixels height.
For clarity we retain the "Touch" density for accessibility reasons on touch devices.


Acceptance criteria:
- Inside the "Customize toolbar" view, remove "Compact" from the density selector
- Current users on "Compact" density migrate to "Normal" density

Attachments

(1 file, 2 obsolete files)

No description provided.
User Story: (updated)
User Story: (updated)
User Story: (updated)
Whiteboard: [proton-foundations]

Team, this bug was linked from a nightly build discussion thread elsewhere on the web, and I read this with surprise:

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. We want to make sure that we design defaults that suit most users and we'll be retiring the compact mode for this reason.

I think it is great that the team wants to ensure that Firefox continues to feels fresh and up-to-date, even though in many ways competitors are still catching up to Firefox (Chrome is now working on a scrollable tabstrip, for example).

However, I think that this is a mistake, and is unlikely to please users - I think it is interesting that the context of this story seems to serve implementers rather than users who use the product ("we have to make difficult scope decisions to ensure Firefox remains simple to use and simple to maintain").

The story says that:

The "Compact" density is a feature of the "Customize toolbar" view which is currently fairly hard to discover

perhaps it is hard to discover, although it appears in the panel that appears after users select "Customize" in the toolbar context menu - likely exactly where people are most likely to look for the density options. Amusingly, a quick look at Firefox 1.0 shows that the Customize context menu item is in exactly the same place, and has similar options to "Use Small Icons" or "Icons and Text".

Personally, I think that the customize UI could be (and the density options) would be easier to use and discover if the options were closer to the thing being customized, rather than in content, with dropdown menus far from the toolbar itself. I had previously filed bug 1660110 to that effect - and once again, this would hearken back to the choice made in Firefox 1.0 (I just started it up to see), where this was a window-modal dialog box.

If this wasn't discoverable enough, we could also add a "Toolbar Density" context menu option like the new "Bookmarks Toolbar" option - not that I would take this seriously, but it is an option.

More seriously, a toolbar density option could be added to step #3 of about:welcome, where we also have options for three themes, and where a density option would be very discoverable for new users.

The story also says that:

and we assume gets low engagement

which sounds to me like we don't actually have hard data around this, and are instead guessing based on what feels like low discoverability (although I would argue that the option is exactly where it ought to be).

We decided to focus on 768 pixels as the minimum height we want to optimize for and the new Proton tabs and address bars account for 92 pixels height, therefore leaving 88% of screen height available for the users in our worst case scenario of 768 pixels height.

Unfortunately, I think that this assumes that there is no taskbar or dock or menubars like exist in all supported OSes that Firefox runs on. On Windows (81% of users, based on the Firefox Public Data Report), the taskbar has a height of 40px. That means that we're ending up with 83% of the screen available for web content, not 88%.

Lastly, the story says:

We want to make sure that we design defaults that suit most users and we'll be retiring the compact mode for this reason.

which feels contradictory to me, as this isn't simply a default - it is the only option.

This bug proposes removal of a feature that I use exclusively on every desktop Firefox install I have. The compact view is elegant and clean, and while not as minimalist as those that the the Firefox modding community produce, it is well designed and professional looking. As someone who uses the feature daily, my feeling at the moment is - if Proton's scope cannot include a compact mode, I don't quite understand the point of Proton. If Firefox ought to be simple to use, it is hard for me to complain about an option that hardly advertises itself (leading to a paradox of choice), and if it is to be easy to maintain - I don't think that the compact mode UI has been hard to maintain.

I hope this doesn't come across as rude or disrespectful but this part "and we assume gets low engagement" is pretty shocking. Can you please at least check the engagement numbers for compact density before you make a decision like this? What if it's nearly 20% of users? I doubt it's that high but it's possible! Please at least check. If it's like 3% or 4%, I guess goodbye compact density :( But if it's in the double digits maybe you should reconsider.

Kinda hard to believe that there isn't a telemetry-probe for this option, since, as yoasif mentioned, it has been in Firefox forever.
Basing this decision only on screen-height seems flawed (eg. currently using compact-density in a 1080px window on a HiDPI screen).

Therefore could we add a probe, at least in Nightly, to determine that the hypothesis is correct?

(In reply to Asif Youssuff from comment #1)

We decided to focus on 768 pixels as the minimum height we want to optimize for and the new Proton tabs and address bars account for 92 pixels height, therefore leaving 88% of screen height available for the users in our worst case scenario of 768 pixels height.

Unfortunately, I think that this assumes that there is no taskbar or dock or menubars like exist in all supported OSes that Firefox runs on. On Windows (81% of users, based on the Firefox Public Data Report), the taskbar has a height of 40px. That means that we're ending up with 83% of the screen available for web content, not 88%.

This is even worse on macOS, where the default menu bar appears to be 22 "screen pixels" tall (44 "Retina pixels") and the Dock defaults to 64. The Dock can be resized, moved, and/or made to slide off the edge, but the usable vertical space on an unmodified Mac desktop appears to be about 86 pixels shorter than the resolution would indicate.

This is mitigated somewhat by the fact that both the menu bar and Dock will slide off the edge of the screen if Firefox is maximized into its own "space", but not every Mac user uses (or even knows about) that feature.

In addition to gathering telemetry on compact density usage, it might be a good idea to get telemetry on the range of Firefox window heights. That is the pool that the tab bar's and toolbar's pixels actually come from.

To be honest I don't think that the window height is that relevant. It does not really matter if there are 500 pixels or 1,000 pixels in the height, some people just want to use the available height because most websites are much larger than the height of the display and for these people it's desirable to get as much on the screen as possible (without any workarounds like using the fullscreen mode or hiding the Dock / task bar).

Also I don't think that it's fair to base a decision on the current usage of the compact mode because Proton has an impact as well. Proton will increase the height of the tab bar by ~ 20 pixels. On my Mozilla related projects (blog, support forum) I already received the feedback from a few users that they will (well, I probably should say: want to) use the compact mode once Proton is released to compensate the new height of the tab bar. So it's not just about taking something away from existing users of the compact mode, it's also about taking something away from some users who are currently using the regular density mode. And that's a data point that can't be measured in advance by telemetry.

The "Compact" density is a feature of the "Customize toolbar" view which is currently fairly hard to discover, and we assume gets low engagement.

For clarity we retain the "Touch" density for accessibility reasons on touch devices.

I find this argument baffling since the "Compact" density is no less discoverable than "Touch" density, both of which can be accessed via:

  1. Right-clicking anywhere on the toolbars > Customize, or
  2. AppMenu > Customize

and yet Mozilla is expecting users on touch devices to be aware of such an option.

It is certainly "currently fairly hard to discover", when the "Customize" button had been removed from the redesigned Proton AppMenu, of which for some reason looks conspicuously similar to that of chrom(-ium) .

I would also like to add that RFP+letterboxing users do not have as much screen height available to them if the "Compact" density is ever retired. Users currently at 1200x800/1400x900, for example, gets a 1000x600/1000x700 inner window when their browser is non-maximized. Inner height can be respectively bumped to 700/800 when maximized, but only when toolbar density is set to "Compact".

Severity: -- → N/A
Priority: -- → P3
Attached image Toolbar size comparison

Compact mode wasn't needed so much with Quantum since it was already quite compact, Proton on the other hand is 26% larger than Quantum and 15% larger than Chromium (measured on Ubuntu). Even with the trend towards larger screens, the current Proton design needs a compact mode more than ever. Compactness is possibly one of the easiest distinguishing features to maintain over the competition and to lose it would be a spectacular own goal.

Engagement numbers aside, I've tried using the Proton "Normal" density for the past 2 days and I'm sorry but it's just awful. It has this jumbo Fisher-Price look & feel to it and it honestly looks silly. Compact looks & feels so much more professional and serious. So even if engagement numbers are low, please consider keeping Compact anyways.

Also, labelling Proton's "normal" density "normal" is not really accurate, it's in-between a "normal" and "touch" density, it should be called "Hybrid" like what Chrome used to have https://medium.com/google-design/redesigning-chrome-desktop-769aeb5ab987. So yes, as others have pointed out, if you get rid of Proton's "compact' density, it means you are only giving the users a choice between "Hybrid" and "Touch", you'll be removing a true "Normal" density. That's kind of a crazy thing to do...

Agree 100% with Kestrel and Will above.

The extra padding in "Normal" mode is just too much at the moment and wastes valuable vertical space IMHO.
I like the direction Proton is going to, but please keep the compactness and refinement of the previous design.
Every vertical pixel counts, especially on 16:9-monitors and smaller screens. Use them carefully :)

And don't forget: on top of the enlarged toolbars (see Kestrel's screenshot), many users have a bookmarks toolbar enabled.

So please consider reducing the vertical size of the Normal mode, or providing a decent Compact mode (or both = current, ideal situation).
Thank you!

we assume gets low engagement

This might be the case indeed, e.g. normal density mode has been good enough for me before Proton.

However, the first thing I did after enabling Proton tabs was precisely switching to the compact mode, since Proton with normal density wastes way too much space. I expect engagement for the compact mode will skyrocket when you ship Proton.

So I ask you too keep compact mode for now, until you have proper stats showing that engagement is still low even after shipping Proton.

And there is another factor:

With Proton, when we are playing a video, the "Playing" indicator make the tab toolbar even taller.

To pile onto the others who've already expressed their concerns: I'm currently using a 2560x1440 (27") screen for work and even with this much vertical real estate I prefer to use the Compact density with the Proton UI. On my other screens (1920x1080 and 1280x800) it is of even more importance for me.

I would therefore like to express my deep sorrow about the possible removal of this option, especially if it is only based on assumptions concerning its discoverability and no hard data.

On top of the concerns raised so far, most of which I agree with: Do the display resolution stats take DPI settings into account? E.g. a display with 2560x1440 hardware pixels and 2x scaling will only show 1280x720 virtual pixels. AFAIK Windows 10 scales by default (not necessarily using factor 2 though) with modern higher-res displays.

Flags: needinfo?(rtestard)

@"The Will of Mozilla Users": While I am also in favor of keeping the compact mode it's not helpful at all to offend the developers and call them "idiotic" and "lazy". I would even say that such comments are harmful. If you really want to keep this mode in Firefox please don't do that. It's definitively possible to have this conversation in a respectful way as enough other people are proving.

(In reply to The Will of Mozilla Users from comment #16)
Please refrain from using that sort of language and keep the discussion civilized.
This is not helpful at all.

Respect for the hard-working people at Mozilla.

Friendly reminder of the rule 4 on commenting and avoiding to spam everyone in CC on this bug (bugzilla etiquette)

No pointless comments. Limit comments on a bug to information which will help with resolving it. Unless requested, additional "I see this too" or "It works for me" comments are unnecessary. Constructive conversations unrelated to the topic of the bug should go in the appropriate discussion forum.

This does include request like "Please don't remove this because...". If you wish to make your voice heard, please open a thread on our Firefox development forum.

I would suggest that posting information about configurations that we might not have considered could help in resolving it.
But if people are just here to say "Me too" without providing new information, then please use the "Vote" button up above instead. 🙂

Is there a way to vote against this change that I'm missing?

I have a strong preference to compactness, will it be possible to match current compactness when this new interface is released? If the answer is no then you are not improving customizability like you imply you think you are. Instead it's a regression without any solid data on user statistics.

Will old userChrome.css work? Mine is (for reference):

/* Reduce the margins within tabs */
.tab-content {
	padding: 0px !important;
}
/* Narrow the gap between the favicon and the title */
.tab-icon-image:not([pinned]) {
	margin-inline-end: 0px !important;
}
/* Change the size of the favicon */
.tab-icon-image {
	margin: 0px !important;
}
.tabbrowser-tab {
	border: 0px !important;
}
/* Change active tab line color */
.tab-line[selected="true"] {
    background-color:#ffbf00 !important;
}

If no, will there be an alternative way?

I will also have to chime in and say that removing it sounds like a bad idea, for the following reasons:

  1. As stated above, there is a false equivalence in the original reason given where "Touch" is kept but "Compact" removed for reasons of discoverability. But, these two options are exactly equal in how they're discovered. Now, if the whole option were to be removed on the basis of this "cannot be discovered"-reason, that'd be consistent. I'd still personally dislike it, but it would have a certain amount of consistent sense. But to only remove one of these options makes no sense, the users still need to be guided to the option after all.

  2. Compact might not be very much needed in Quantum's design, because the standard density is already so much more compact than competing browsers. But, Proton is significantly bigger and uses up a lot more screen estate. As this is used from the top by default and most desktop monitors are wider than they are tall, this uses up "good" screen estate. What works against this is that anyone who uses the standard layout in Quantum can then swap to compact in Proton (and I'd argue it should be the default to make the changeover less jarring). If this option is removed, Firefox ends up presenting less actual web page than competing browsers, without adding any value in the space taken away - there's no new functionality after all.

  3. One of the frequently heard criticisms of those who try the curent Proton mode is the extra screen space used by the design. It feels weird to not only work with this feedback, but rather go the opposite direction and remove the ability for the user to partially work against this increase in screen estate use.

i strongly disagree on the removal of "Compact" option.
although my display is 15.6inch with a resolution of 1920*1080, i chose compact to reduce the available space consumed by the UI and generally that's how i prefer it, it seems to me less cluttered.
with the same logic Mozilla should disable support for AMD processors because only 10% of the users have AMD CPUs.

i see no reason to remove the "Compact" option.

This story assumes that compact mode is a remedy small screens only, which I don't agree with. I like the Compact mode, and I use it on a 27" 4K display.

I like to maximize page area. I prefer minimal browser chrome as an aesthetic choice. I already use auto-hide options for the top menu and the Dock on macOS.

The Normal skin emphasizes the toolbar buttons, but I never use them. They're inconvenient to reach on a large screen, and I prefer to use keyboard shortcuts and context menu instead. So I dislike the Normal skin, because it takes away page area that I value, and spends it on something I find redundant.

As a user of Mozilla Firefox with a 24 inch screen who uses their computer with a screen resolution of 1360x768, I came here to express my absolute disagreement with this suggestion.

I use the Compact Mode myself because I prefer to have the browser's UI nice and small, rather than mid or big sized.

I do not want to be forced to use a bigger size preset. Hell, I have to use extra userChrome.css based tweaks because Firefox doesn't give me the choice to make things a bit more compact than they currently are, nor does it allow me to customize things myself otherwise, like for example the size of the tabs.

Please stop trying to remove relevant browser features. Thank you.

I've been meaning to try Proton for some time and yesterday I finally gave it a try. The first thing I noticed was the tab bar. I was fine with the normal density before, but now I switched to Compact right from the start. I have a 32" 4K monitor, but I want to use the browser to see web pages, not the browser UI, no matter how pretty it might be.

And it's already been said, but the phrasing in the issue description absurd. You want to remove Compact because it's hard to find, but keep Touch for clarity? What's that even supposed to mean? Why do you hate my screen space?

That's not to mention how useless the tab bar is now: I can see exactly two and a half letters from each of my tab titles. Sure they're a nice chunky bit of screen to tap on with that 2:1 aspect ration, but it's terrible UI.

I use above 768 pixels and one of the first settings I always change is Density from Normal to Compact, so therefore I'm going to assume it gets high engagement.

If, however, a decision such as this is to reduce the problem of low engagement, then I do agree that it will be a success, as it will inadvertently reduce the Firefox user base.

Hi,
I wanted to share my thoughts on this.
I use FF on 24' FullHD monitor and 15,6' laptop. In both cases I use only Compact mode because it gives me more space for the actual Web page content.
I tried to compare the existing compact+normal mode with the Proton ones available in Nightly.
Proton itself makes UI elements oversized compared to existing ones.
By potential removal of the compact mode once again the users will become forced to sacrifice actual content space to the oversized UI elements

I strongly disagree with the removal of the Compact option especially with provided arguments from the description.
Touch in the same place, how come that it should stay and Compact should be gone...

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 just turned this on and it's an improvement. I'll be turning it on in all of my devices. Perhaps the issue isn't the feature, but that it's not in the standard preferences menu? One could also do heuristics, and use it when vertical size is less than 768 if the user didn't override how they wish it to be.

Attachment #9205949 - Attachment filename: file_1693028.txt → ?
Attachment #9205949 - Attachment is obsolete: true
Attachment #9205949 - Flags: feedback+
Points: --- → 3
See Also: → 1697293
Assignee: nobody → bwinton
Status: NEW → ASSIGNED

It's confusing to me that Bug 1697293 and this one both seem seem to be moving forward. Is Proton going to support compact mode or not?

Flags: needinfo?(bwinton)

The word from Product Management is still that we should remove this, for the reasons listed in the User Story. The other bug was filed and fixed by a contributor, but I appreciate the work that went into it, and if we ever re-add the compact mode toggle, I'll be very happy that Tim made it look much better!

Flags: needinfo?(bwinton)

(In reply to Blake Winton (:bwinton) (:☕️) from comment #36)

The word from Product Management is still that we should remove this, for the reasons listed in the User Story.

Although these points have been mentioned before, I would like to emphasize that the "reasons listed in the User Story" are pretty dubious:

  • "we assume gets low engagement" - This assumption has absolutely no data behind it
  • "We want to make sure that we design defaults that suit most users" - This reason doesn't really make any sense. Since "compact" is not the default, its behavior/appearance has absolutely no impact on whether the design defaults suit most users.
  • The hardware report still has an open needinfo that needs to be answered. And regardless of the answer to that question, it is very unclear why a larger screen size would obviate the need for compact mode.

i agree with Kirk above.
product management needs to understand that if a random user/reporter finds a feature not useful, it doesn't mean that all userbase think the same. you must not "assume" something isn't helpful, you must be 100% sure about it.
i also think that the zoom controls UI in the tab bar is useless but i didn't file a report to remove it. i still can't understand how a new user isn't able to find the density options when customizing the UI. it's very clearly indicated in the bottom of the window!

since another user created a patch, why don't you implement it if further testing proves it will work as expected?

Once more, even if this comment might be regarded as spam: This bug relies solely on an assumption. I would, on the other hand, assume that enough users have voiced not only their opinions here and on Reddit, but also their specific use cases in which the compact density plays a role.

Should Product Management really insist on removing this option I have a simple prediction: Firefox will decrease its (usually loyal) user base once again by removing more customization options. I would be very sad to see Firefox become irrelevant but - using the browser 8 hours+ per day as part of my job - unwilling to accept the overly huge Proton UI in normal density.

Hi here, this is becoming ridiculous/illogical.
As was stated multiple times before, this ticket lacks logic in it. Indeed, it is based only on assumption without any figures or facts.

I wanted to emphasize that
https://bugzilla.mozilla.org/show_bug.cgi?id=1697293
Introduced some code changes to the Compact mode and it looks compact within Proton redesign.

I can theorize that this bug was created due to the cost optimizations, but right now there is a working solution for the matter.

Seems like the "effective Product Management" tries to ignore consumers feedback.
I am calling to them again.
There are new factors in place that at least require to revising the decision made earlier within this ticket.

I can only guess that since Bug 1697293 and Bug 1697623 are being worked, the objective is to replace the current Normal density UI for the Compact one and that it will become the new Proton Normal density.

If that is the objective, i think that is a good solution.

Can someone from Product Management or UX please let us know what's going on? A few good and valid points have been brought up here...

(In reply to lunosouroboros from comment #42)

Can't this be put in the backburner until there's a valid source of information proving that the amount of people who make use of the Compact size preset is not big enough to justify the resources that supporting it may require, at the very least?

FWIW, compact mode didn't need much maintenance over the years and already kind of works with Proton. It's a fairly cheap feature to support, especially since we need to keep the UI density infrastructure anyway for touch mode. So from an engineering perspective there's little to be gained from removing compact mode.

(In reply to Dão Gottwald [::dao] from comment #15)

On top of the concerns raised so far, most of which I agree with: Do the display resolution stats take DPI settings into account? E.g. a display with 2560x1440 hardware pixels and 2x scaling will only show 1280x720 virtual pixels. AFAIK Windows 10 scales by default (not necessarily using factor 2 though) with modern higher-res displays.

I took a look into this. The display resolution stats do not appear to take DPI scaling into account. As I understand it, the screen resolutions in that hardware report are obtained from the Telemetry Environment's screenWidth and screenHeight values. On Windows, those values are generated here, using EnumDisplaySettingsW. The docs for EnumDisplaySettingsW state:

This API does not participate in DPI virtualization. The output given is always in terms of physical pixels, and is not related to the calling context.

Flags: needinfo?(rtestard)

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #53)

(In reply to Dão Gottwald [::dao] from comment #15)

On top of the concerns raised so far, most of which I agree with: Do the display resolution stats take DPI settings into account? E.g. a display with 2560x1440 hardware pixels and 2x scaling will only show 1280x720 virtual pixels. AFAIK Windows 10 scales by default (not necessarily using factor 2 though) with modern higher-res displays.

I took a look into this. The display resolution stats do not appear to take DPI scaling into account. As I understand it, the screen resolutions in that hardware report are obtained from the Telemetry Environment's screenWidth and screenHeight values. On Windows, those values are generated here, using EnumDisplaySettingsW. The docs for EnumDisplaySettingsW state:

This API does not participate in DPI virtualization. The output given is always in terms of physical pixels, and is not related to the calling context.

Oh very good point. We're talking about logical resolution, correct? To find this out on various machines I set up at work, I just go to https://bestfirms.com/what-is-my-screen-resolution/ but make sure page zoom is at 100%. Looking at https://data.firefox.com/dashboard/hardware , I'm almost certain that the 2nd most common resolution (1366 x 768) , almost all of those computers are set to 100% display scaling, so that 1366 x 768 number is the same. But the most common resolution (1920 x 1080) are more likely to be at 125% display scaling, which is a logical resolution of 1536 x 864. 864 is not a lot of room at all, I would recommend compact density to those users too.

Depends on: 1698100
Depends on: 1698171

Please don't get rid of the option to choose compact mode.

I don't know what I can say to try and convince you that it's one of the few remaining crucial accessibility customization options for smaller viewports. Honestly, I don't think it needs explaining. The fact is it's an extremely natural thing to support, under the supposition you're actually interested in supporting many kind of desktop setups and not just "the one".

I also don't suppose there's much point in pointing out that on the Firefox Reddit, people are exasperated at these constant encroachments on usability. Most are just baffled at the idea of removing important customization options, and then the other half isn't even going to bother saying anything because Mozilla devs have never bothered to seriously listen to people on these issues and they're not going to start. And they're not wrong: whenever I've raised my voice here on usability/design issues here I've only ever been met with microaggressions from devs who take an "us vs the world" approach. And people who do speak out are said to be "just a vocal minority" vs the invisible majority that most definitely just wants the compact mode removed. So in that vein I don't really expect much by posting this comment, because I also don't expect anyone to give these concerns even a nanosecond of serious consideration, but I can't not post about it either.

Software needs to have options like this. You don't just remove them because "there's low engagement". Maybe you should consider that the application isn't making it easy to discover, rather than that nobody wants it. Screen space is important. Having a good experience on small monitors (or larger monitors, for those who want it) is important. Especially in this day and age when every application (and web designs, too!) just seems to be itching to find new ways to waste screen space needlessly.

Like a ton of people on Reddit are saying, it's really becoming impossible to keep loving and supporting Firefox. It seems you are all just committed to making software that satisfies arbitrary metrics rather than people.

If all the decisions that make what Firefox is going to be are going to be decided by tests and users engagement, this is not the browser I’d like to advocate for. You still can make a good product without removing all the options people used before.

(In reply to Will from comment #54)

But the most common resolution (1920 x 1080) are more likely to be at 125% display scaling

FWIW, the Lenovo Yoga C630 has a resolution of 1920x1080 and defaults to 150% scaling (Windows 10).

(In reply to Mike Hommey [:glandium] from comment #58)

(In reply to Will from comment #54)

But the most common resolution (1920 x 1080) are more likely to be at 125% display scaling

FWIW, the Lenovo Yoga C630 has a resolution of 1920x1080 and defaults to 150% scaling (Windows 10).

Oh wow, so 720 pixels high on those "what is my resolution" websites? Now I'm really wondering how common 150% display scaling is on 1080p computers. Compact density is simply the only option if your logical resolution is only 720 points tall.

FWIW, the Lenovo Yoga C630 has a resolution of 1920x1080 and defaults to 150% scaling (Windows 10).

I believe this works out to 1080px/1.5 = 720px in available height. Comment 1 indicates that Windows has a taskbar height of 40px. I believe that this leaves 680 pixels of usable height. This is substantially less than the 768 pixel minimum height that the user story says that we are planning to optimize for.

The bug report doesn't tell the whole story of why people use Compact. My display is 1280×800 but I use Compact because I dislike Normal's empty-space-for-the-sake-of-empty-space design.

"We assume gets low engagement"... evidence please.

If I wanted a browser that I couldn't customize, I would've already downloaded Chrome.

(In reply to testspamacct from comment #61)

The bug report doesn't tell the whole story of why people use Compact. My display is 1280×800 but I use Compact because I dislike Normal's empty-space-for-the-sake-of-empty-space design.

"We assume gets low engagement"... evidence please.

If I wanted a browser that I couldn't customize, I would've already downloaded Chrome.

Exactly. I assumed 125% display scaling would be by far the most common on 1080p computers but if it turns out a lot of these 1080p computers are set to 150%, they have no choice but to keep compact density.

I think that the default is different between laptops and desktops. If I set my Windows 10 laptop to 1920x1080 resolution, it defaults to 150% scaling, which it labels as "Recommended". If I do the exact same thing in a virtual machine, it defaults to 100% scaling instead. I don't have an actual desktop machine handy to check, but a coworker claims that she is sure she remembers 100% being the default on her desktop.

I have never used Proton before but even with current normal density doesn't fit into my workflow. I used Firefox for GitHub browsing and revising my HTML notes for most of the time, and I realise that how important the role of the compact density on maximising the available screen resolution that I currently have (1366x768) with a combination of window manager plus toggle oof the bookmark bar. IMO, it is a great UX design that I admire and one of the features that distinguishes Firefox from Chrome variants.

Unless this feature causing severe issues such as potential security risk, unoptimised memory usage, dragging overall program's performance etc, I don't see the reason why this feature should be removed for Proton release. The reason stated in the User Story doesn't convince me much. If low engagement can justify the reason of removing a feature, I'm afraid that I couldn't see how the dev wouldn't use the same reason to remove other useful customisation options like setting customise Homepage and userChrome.css.

The Preference option offer by Firefox are often the starting point of the user to customise their browser. This inspire many users to make more efforts to learn how to do more customisation and struggle on doing it better. And often time, compact density is one of such inspirations. Taking this away will result disappointments from the user base that Firefox currently have, and by going down this path (or this way of thinking), Firefox will fail to standout to its competitors (Chrome variants, Safari) since it voluntarily gives up its obvious advantage for the niche reason.

I think this is a big mistake. Modern interfaces need to start taking up less space, not more. I get that some users using touchscreens need larger elements to interact with, but I think the correct solution is to replace the current "normal" density with compact.

See Also: → 1698244

Hello everyone.
Even if you care a lot of about his feature, please don't post me-too comments or opinions in this engineering bug tracker.
Technical insight, like comment 53 or comment 58, is always welcome.
Otherwise, we may have to limit commenting in the bug, and we don't like to do that.

The Engineering team is well aware of the community feedback.

How can you express your opinion then?
You can continue commenting in the Reddit/HN threads that made this bug viral, both are frequented by Mozilla employees. Or you can chat in real time with us, see https://wiki.mozilla.org/Matrix, and join https://chat.mozilla.org/#/room/#fx-desktop-community:mozilla.org.

(In reply to Marco Bonardo [:mak] from comment #67)

Hello everyone.
Even if you care a lot of about his feature, please don't post me-too comments or opinions in this engineering bug tracker.
Technical insight, like comment 53 or comment 58, is always welcome.
Otherwise, we may have to limit commenting in the bug, and we don't like to do that.

The Engineering team is well aware of the community feedback.

How can you express your opinion then?
You can continue commenting in the Reddit/HN threads that made this bug viral, both are frequented by Mozilla employees. Or you can chat in real time with us, see https://wiki.mozilla.org/Matrix, and join https://chat.mozilla.org/#/room/#fx-desktop-community:mozilla.org.

Perhaps instead of telling users to be quiet or to engage developers in intimidating chat environments you developers come and meet us.

Whoever is in charge of the overall Proton Re-design should do an AMA on reddit.com/r/firefox The community is a decent size and active. And reddit is somewhere that can also engage a wider audience. It also has a robust upvote/downvote system that can filter questions.

It is time for developers to do some outreach and talk directly to the user base.

All I can do is summarise the main points of criticism, h/t https://www.ghacks.net/2021/03/14/mozilla-plans-to-remove-the-compact-density-option-from-firefoxs-customize-menu/:

  • Mozilla does not seem to have hard data about usage numbers.
  • Compact mode gives more height to the displayed sites in the browser.
  • The upcoming Proton design refresh takes up even more space than current versions of Firefox.
  • Lack of discoverability could be changed.
  • Operating system toolbars and docks take away space as well.
  • Compact mode is used on screens of all sizes, e.g. when users display two browser windows side-by-side.

I agree with all of the above and then some. Happy to continue in a more detailed discussion on Reddit, of course, but the 'community feedback' cannot be forced into a silo of its own if you wish to retain its impact.

bugzilla.mozilla.org could have a "Vote Against" button, in addition to the existing "Vote" button.

That way, users could register their disagreement with a proposed change without "me too" posts.

Also, the ratio of "Votes" versus "Votes against" could be construed as a small sample of "hard data".

Maybe worth mentioning here, given some misunderstandings elsewhere – the advanced (about:config) preference:

browser.uidensity 1

– not to be confused with the (non-advanced) everyday GUI to customisation.

Relevant Hacker News thread: https://news.ycombinator.com/item?id=26464533

(In reply to Danny Shintag from comment #69)

All I can do is summarise the main points of criticism, h/t https://www.ghacks.net/2021/03/14/mozilla-plans-to-remove-the-compact-density-option-from-firefoxs-customize-menu/:

I think this is a great summary. I would like to add that on macOS it's also quite accepted to run applications with non-maximised windows, so the screen resolution should not be used as the primary measure of the screen estate available to a Firefox window.

And, if your metrics show that the majority of users run maximised windows, it's not necessarily because they want to. I had to switch my old 13" Macbook to the "More Space" mode (for non-macOS users, essentially to use a UI scaling factor below 1.0) and almost give up on non-maximised windows because over the last 5 years or so most apps (not only FF) altered their UI layouts in a way that leaves the user with less usable space. So yes, if you gather telemetry from my install, it would seem like I only run maximised windows and use a <1.0x scaling factor but it's not because I wanted to in the first place.

(In reply to Marco Bonardo [:mak] from comment #67)

Even if you care a lot of about his feature, please don't post me-too comments or opinions in this engineering bug tracker.

I think this is generally a basic netiquette but in this case the ticket has a statement that the compact mode "gets low engagement" which is ostensibly used to motivate feature removal. Also, see my earlier point about the interpretability of the telemetry trends (not to mention that the baseline should be how many users altered any UI preferences given that the default option skews the results; if 3% alter UI settings and 2% use compact mode, it [roughly] means that 2 out of 3 users who go into UI settings wish to use the compact mode).

First, I'd like to thank everyone for the feedback provided. People in charge of making this decision have been notified about it.

Unfortunately, due to an even wider sharing of the link to this bug, the bugmail notifications are increasing, and me-too comments are not providing new information. I'm now restricting comments to this bug.
You can continue using the communication channels I suggested in comment 67, plus https://discourse.mozilla.org/c/firefox-development/, that I forgot there.

Restrict Comments: true
Depends on: 1698896

Since many people are coming to this bug in support of compact mode, I'd like to point out that I just landed a change in bug 1698244 that reduces the height of the toolbar. This makes the difference between Normal and Compact density much smaller.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #78)

Since many people are coming to this bug in support of compact mode, I'd like to point out that I just landed a change in bug 1698244 that reduces the height of the toolbar. This makes the difference between Normal and Compact density much smaller.

Just so we're clear, Proton Normal still consumes more height than Normal mode as shipped. (Differences may vary across OSes.) So while this is good progress, it wouldn't necessarily justify removing Compact mode.

Question for these who propose this change should be - will this change make Firefox better and more users will be using it because of this change? I'm very skeptical that it will.
Because for now, based on "arguments", looks like this change doesn't have any engineering benefit at all and it's just change for change.
What's more, updated Proton GUI will consume more space based on project design, so Compact Density mode could be more useful than ever before, especially when it will be more discoverable.

It really pains me to look on diminishing usage share of Firefox compared to other browsers, which could be even correlated and related to various changes made to Firefox by Mozilla.

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

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. This change will be addressed in bug 1703254.

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1703254

Comment on attachment 9208230 [details]
Bug 1693028 - Hide compact mode for people who don't use it, and Density menu when there's only one option. r=Gijs

Revision D107913 was moved to bug 1703254. Setting attachment 9208230 [details] to obsolete.

Attachment #9208230 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.