Settings: continue to invest in UX

[bpasero]

Refs: https://github.com/Microsoft/vscode/issues/50496

This is a meta issue about the general UX of the settings editor. I think where we are at currently is a one-to-one transformation of our old settings experience to a new experience that shows UX controls for changing values instead of having to type into the editor. The next logical step for me would be to improve this experience to fix some of the shortcomings we have with the classic settings editor.

Settings Inheritance This to me is the biggest source of confusion for new users. Settings can be defined globally, per workspace, per folder and even some can be defined per language in all of these levels. Instead of doing full context switches between these categories, can we maybe just show the various configurations per setting when this applies? I would think that most often only few settings are configured on the other levels. This area seems to be something where we should just explore and throw ideas in to see if they work.

Readability The translation of our JSON schema to a settings description imho does not work well and needs a revisit. There are several issues:

• we often use formatting to show the available options that only works well in a monospace font of the editor
• the text is quite long in many cases making the visual appearance of some settings quite heavy

Maybe we should only ever show a single line of the settings description to balance the visual appearance when many settings are showing?

I feel like all our settings need some general authoring to be easier to understand. This is not primarily an issue with the new settings editor, you could argue we had this issue before already. But now the description is much more prominent compared to before imho. We also seem to generate a description out of the setting ID actually:

Table of Contents I also feel like the tree structure for all settings could be improved. I like the idea of showing a table of contents to the left (master/detail) and then clicking on an entry filters only to these settings. When typing and searching I would simply show all settings but not allow to expand/collapse any.

Separation I feel like the header with all the controls should be more clearly separated from the settings, it currently collides with the UX of individual settings imho:

Balance I also feel like the settings show up quite unbalanced in cases like this:

Usability Some settings like files.exclude could really benefit from a UX control to put in the values. I know that work has already started on that, but wanted to add this for completeness.

/cc @stevencl @misolori @joaomoreno

[roblourens]

All good points.

Balance - the value is supposed to be a fixed width currently. Select dropdowns are sized by default to the width of the widest option. And that's something I need to work out, do I force them to be narrow, truncating a wide value?

[octref]

fix some of the shortcomings we have with the classic settings editor

I think we need some user-study to understand what are the "shortcomings". To me, I feel areas where the GUI editor (as of now) helps most is discoverability of common settings and seeing which settings differ from default values. Other areas, such as the ease of configuring specific setting values (files.exclude, for example), I'm not sure if adding more GUI would solve the problem. Maybe the problem is in the docs for that setting item.

Overall: Instead of making GUI editor the solution, first see what the problems are and what are the possible ways we can solve them (including using the GUI).

One gem I found from the original thread (#3355) is the mockup from @bgashler1:

I'm wondering if it's possible to make a GUI setting searcher/previewer that's just on the left side, for the improvements on setting discoverability, readability of doc and navigability, and leave most of the value editing job to the JSON editor because I think it's the best fit for the job.

My argument is that trying to hide all the JSON from users might distance them from learning the way VS Code works. Other than settings, there are also launch.json and task.json that users need to learn anyway. Teaching them how to use VS Code's IntelliSense for JSON editing + improving the inline docs might work better than coming up with specialized editors for each complex setting item.

[roblourens]

Lots has changed so I hope this is covered by other issues

https://github.com/Microsoft/vscode/issues/55791