Explore UI density modes

[daviddossett]

We hear quite a lot of feedback from the community on how they would like VS Code to look and feel. One theme that often comes up is related to UI density.

This feedback spans specific usability concerns like the activity bar being hard to understand without labels as well as broad feedback like the UI feeling overall cramped and harder to interact with given the close proximity of buttons and other elements.

On the other side, many seek a more compact and space-efficient UI. Using the activity bar example, some users would prefer a hyper-compact version that doesn't take up any horizontal space. Or perhaps they'd like the titlebar to use as little space as possible.

Density modes could apply to everything from low-level font/icon sizes to widgets like toolbars and lists. At a high level, they could impact larger UI parts like the status bar, title bar, and more.

This issue will explore what it could look like to feature UI density modes in VS Code.

Rough Sketch

Here's an idea of what this could look like to get the ball rolling. Not intended to capture every detail:

https://user-images.githubusercontent.com/25163139/206812861-0312f871-84b4-477b-bed1-b49e336d43c5.mp4

[usernamehw]

Would be nice to configure parts separately:

"...": {
    "titleBar": "default",
    "statusBar": "comfortable",
    "activityBar": "compact"
}

[daviddossett]

Would be nice to configure parts separately:

"...": {
    "titleBar": "default",
    "statusBar": "comfortable",
    "activityBar": "compact"
}

This could make sense—certainly the first thing I expected to be asked about 😉

My first question is how the state of each UI element would react to the density modes if they were individually set. Does the density mode stomp on those changes? do we introduce a "custom" setting?

Also curious how deep this would go since density could be considered as applying to major UI parts (e.g. the status bar) but also to any number of tiny low-level UI details. I'd prefer to avoid a huge settings surface area if we allowed such customization.

Open to ideas here.

[Kietyo]

Thanks for exploring this. Personally I would always use the compact setting, here are the settings that I'd like to be able to change:

• font size of the file explorer (so I can decrease font size to display more items)
• top/bottom paddings of items in the file explorer (so I can decrease padding to display more items)

I have no preference for whether the settings would be globablly applied or applied based on the density mode. For my use, I would always use compact, so maybe having those settings be global would be easier to implement for y'all.

[usernamehw]

My first question is how the state of each UI element would react to the density modes if they were individually set. Does the density mode stomp on those changes? do we introduce a "custom" setting?

One setting can be enough (string(global) or object(customized)). When switching density mode through the UI(Quick Pick) - if setting is of type object(user customized), then show notification with buttons or modal dialog with warning that it will overwrite it.

Also curious how deep this would go since density could be considered as applying to major UI parts (e.g. the status bar) but also to any number of tiny low-level UI details. I'd prefer to avoid a huge settings surface area if we allowed such customization.

One way is to start with the biggest chunks of interface and wait if users ask for smaller UI parts customization.

[daviddossett]

I explored what it could look like to have density setting for each major UI part:

https://user-images.githubusercontent.com/25163139/207733129-c0b6b49f-61c4-4d9c-b292-16c136d52d7b.mp4

This is interesting but does make me worry that it's too easy to have weird inconsistencies across the workbench. For example, if I set the sidebar to comfortable, and the density of lists (e.g. Explorer) are affected, does that mean that lists elsewhere in the workbench (e.g. quick pick, lists is secondary sidebar, panel, etc.) are unaffected?

Other feedback from the team on the original global workbench setting:

• We should decouple things like font size and activity bar labels from density. This should be about spacing, not other details.
• We should also decouple positioning (e.g. moving the activity bar to sit above the sidebar). That could be set separately like we do for workbench.sideBar.location

[albertelo]

We should decouple things like font size and activity bar labels from density. This should be about spacing, not other details.

While I agree that density shouldn't necessarily change the font size, the main motivation for this change would not be covered anymore, right?

[NuckChorris]

Any movement on this? It's one of many blockers preventing some of us from updating to the latest version

[kiprou]

I must agree with @albertelo that direct access to the workspace's font-size, font-family, letter-spacing, and padding would knock everyone's socks off.

However, I'm happy to see this new issue, since it at least tries to address workspace padding. This would be a welcome win for accessibility and customisation.

I'm in favour of the global control from @daviddossett's first comment, combined with the ability to override each major UI element's density.

Regarding this:

If I set the sidebar to comfortable, and the density of lists (e.g. Explorer) are affected, does that mean that lists elsewhere in the workbench (e.g. quick pick, lists is secondary sidebar, panel, etc.) are unaffected?

You have to decide what's worse. If overrides leak, the user must manually clean up unwanted leakage by adding additional overrides. If overrides don't leak, the user must manually add the same override to all desired elements. Both tasks are potentially repetitive, but the latter feels more proactive, since it doesn't introduce unintended clean-up work.

[daviddossett]

Any movement on this? It's one of many blockers preventing some of us from updating to the latest version

I'm coming back to these explorations in our February iteration. Will keep everyone posted here.

[EXHades]

February is almost over，Is there any progress?

[daviddossett]

I've had to defer this effort temporarily given a bunch of other high priority efforts within the VS Code team. Unfortunate, but this happens time to time given how much each of us on the team are juggling.

I promise I'll come back to this as soon as I can.

[lehni]

Given that vertical space is generally more sparse than horizontal space, I think the title-bar should entirely go. I would recommend removing it entirely and moving the tabs there, as shown in this screenshot.

[DeltaRazero]

Any idea if the May iteration plan will see continuation of this issue?

[dphov]

Any update?