Open laurentlb opened 1 year ago
adding @daviddossett for thoughts from the UX side. We can discuss more about it if needed when we meet
@kieferrm FYI as well since we've discussed density in the past.
First of all, I like the idea of a smaller issue to discuss changes outside of #519.
Where exactly would the font-density setting apply in all of the workbench UI? Or only in views?
When we discussed #519 a few months ago, one idea was to scope the solution to lists/trees only and probably only allow to change the font size and maybe line height, similar to what the editor allows. Applying this only in selected locations of the UI reduces the chances of UI breakage in places where we have hardcoded assumptions about label sizes.
Where exactly would the font-density setting apply in all of the workbench UI? Or only in views?
IMO it should be across the whole UI (except the editor). The feedback we've gotten is so scattered that just making one area larger wouldn't suffice. That said, just changing the most critical views would be a win.
The screens attached as examples are quick and dirty. Ideally changing spacing a bit to adjust to the new font sizes would be useful. I'm aware this might be already out of scope.
One question I have: given that elements will automatically become bigger when using a bigger font size, what's the real difference between zooming the workbench vs. increasing font size + elements naturally getting bigger?
Have we been able to compare what the two approaches might look like? Off the top of my head, the main advantage I can see for isolating font size is that things like icons and larger UI parts like the sidebar wouldn't necessarily need to grow/shrink like they do with zoom.
One question I have: given that elements will automatically become bigger when using a bigger font size, what's the real difference between zooming the workbench vs. increasing font size + elements naturally getting bigger?
My understanding from discussing with some accessibility experts and reading some of the bug reports is that the browser zoom makes parts of the UI harder to use because it makes the layout harder to use. Browser zoom doesn't fix relative size differences. It will zoom all those sizes up and down the same.
The proposal we shared would only increase font-size thus keeping the rest of the layout almost intact (unavoidably making the font size bigger will decrease screen density)
Following up my previous comment and after discussing with @daviddossett a bit more, here's a comparison between browser zoom and increasing only the UI font-size and how the layout changes. As you can see (although not sure how accurate this experiment is) the browser zoom changes all of the UI's layout while just increasing only the UI font-size the layout is not affected as much
Since Slides downgraded the images significantly, here are all images in better quality: font density.zip
Author of #144365 here, Lauren referred me to this thread.
I believe a more proper approach could be to keep the text inside of the bar or panel it's in, or a fair compromise could be to limit the font size/expand the bars and panels proportional to the font size. The font family shouldn't be a major change, just the font size.
I talked with Lauren and I'll open a PR to pass IConfigurationService
everywhere, which should be a solid start. Once we figure out how to handle font density and font sizes, we can pass those config values to the individual elements.
FYI I've started a somewhat related issue on UI density all up that could leverage a font setting as shown here: https://github.com/microsoft/vscode/issues/168671
I took a quick look at how zoom compared to subtle font size changes and here are my initial takeaways:
This feature request is related to #519, but I would prefer to discuss this new proposal separately (the other issue has hundreds of comments, with many different ideas). We use VS Code at Google and we have an internal issue for this with 314 upvotes. So we decided to take a closer look at the problem and found that it is a request mainly for accessibility, not for more customization.
The default guidance is to use the browser zoom to increase the font size. This can work well in some cases, but it leads to less information density (because it makes everything bigger, including margins, etc.).
We don't want to let users set their own font size, as it would be hard to test and lead to many UX challenges. Instead, we propose a setting with two or three values. In the mocks below, the default setting is the current font size, "comfortable" increases everything by +1px and "large" makes all UI font-sizes +2px. The sketch is very basic and would need some re-thinking of spacing too.
@albertelo made these mocks, with 3 options for a "Font Density" setting
Default:
Comfortable:
Large:
If we used the browser zoom instead (as currently recommended), we would have much less information on the last screenshot.
Being able to change the size of everything (browser zoom) or just the text (this proposal) is not new. For example, Android accessibility settings have the same options:
fyi, we have also used similar settings in our other internal developer tools. This was useful for accessibility.
Next steps
If there's agreement on the goal, we can try to revive #144365 (after splitting it). A large part of that PR makes IConfigurationService accessible to many locations. While it touches a lot of files, I believe this could be relatively safe to submit.
The actual user-facing change will need careful review and testing. We'll be happy to help test the change, roll it out to our internal users, and collect feedback on the change.