Make settings UI look more like one unit and easier to switch to global/workspace settings

[bgashler1]

16764 Design task:

• [x] The settings editor currently looks more like two editors. How can we improve it to look like one unit?

Extend Search to both Default (LHS) and Editable (RHS) settings editors. Search will filter in Default settings where as in Editable settings it highlights settings matched in Default settings.

• [x] Also, how can we support quickly switching between Workspace and User settings without having to go through the app menu.

Show User and Workspace settings as tabs next to Search to easily navigate and discoverable. When there is no workspace, Workspace settings tab is shown disabled.

• [x] Open Workspace Settings message box opens plain settings.json

cc @sandy081

[sandy081]

@bgashler1 I started working on this. This is what I am thinking

Layout

• Extend the header bar (with Search and any additional actions) across two editors (left, right)
• Let two editors has separate header describing themselves (say Default Settings, User Settings etc)
• On search, default settings are filtered and shown those matching the search criteria (like how it is now). But, I do not like to have the same behavior on right side editor (editable settings) because this is editable and will not give good user experience. Instead it highlights those settings which are shown in default settings. Let's say Default settings show font size setting and if right side has this setting then it is highlighted. Any thoughts?

Switching settings

• One proposal would be to provide an option in the header bar to show Workspace settings. Idea is ability to show either or both settings on the right side. Any UI suggestions will be helpful.

[bgashler1]

Similar issue #16696

[sandy081]

@bgashler1 Take a look at the following video that has changes to layout as explained in comment.

Suggestions and feedback is very much welcome.

Some feedback from the team

• How helpful is to show the count (Showing 10 of 260 settings)? IMO it's ok to me to leave it or remove it. From UI point of view, I feel it makes Search bar looks better than with out it.
• Since LHS and RHS look similar, we need some user affordance to say users that RHS is editable. (This is also true before). This is especially for new users.

I think new users start performing actions and might (or not) slowly learn that RHS is editable. There is also a comment on the top to say that RHS is a file that can be updated. May be we can have a different bg color for LHS to say that it is read only?

Next step is to integrate workspace settings in this settings editor

[gulshan]

There can be a link/option in the UI to facilitate easy switching between user settings and workspace settings.

[sandy081]

After further thinking, I think, it's better to place showing count message in LHS (as before). Because this message belongs more to Default Settings.

[bgashler1]

@sandy081 it's interesting to see your highlighting idea in action. I think I would need to play with it.

cc @chrisdias, @seanmcbreen

By the way, I have a few different design ideas (below) that might help with the LHS and RHS similarity problem and also address @gulshan's comment. All of these involve keeping the search box localized to the left while still making the whole settings area look like one unit.

1) Full-width header and tabs

Pros: tabs are fast and intuitive at helping users know there is more content here. Cons: these tabs might be a little too subtle on a gray header.

Alternate (use dropdown instead of tabs) Pros: it follows what we do in the panel for switching content and avoids introducing a new tab paradigm. Cons: it's not as fast to switch as tabs.

2) Ribbon symmetry with accordion

Pros: it allows you to compare User and Workspace settings in one place Cons: do we even need to see both at once?

3) Minimalist with right-aligned tabs

Pros: Very clean and lightweight Cons: we lose the top help tip that is in the other designs.

So far, I'm getting the best feedback about Design # 1. Your thoughts?

[bgashler1]

@sandy081: You might be surprised I brought back the header background color, considering #17103. We can fix that issue using a translucent white/black instead of an opaque gray. It would be rgba(0,0,0,.5) for light themes and rgba(255,255,255,.03) for dark themes. This would appear the same in default light and dark while also blending nicely in other themes.

[gulshan]

If "User Settings" and "Workspace Settings" menu items under "Preferences" are merged to just "Settings", # 2 seems a better option showing both. Because then, which one of the two is intended by the user is not known. Otherwise, # 1 a is better than others I guess.

[sandy081]

@bgashler1 Firstly, designs are very good and a fantastic job.

All options are good and share same advantage of easily switching between settings and same disadvantage of not intuitive to the user that LHS is Default Settings.

My thoughts:

1. I feel, having a tool tip on the top will not help much because New users: It is not clear that which editor is editable and which is readonly given all of them look alike. They learn the right side is editable by either trying out the actions or just by trying. I think not many users will read that to understand that RHS is editable. We already provide a comment in the RHS editor. So,I feel better user affordance is helpful than having a static help tip. Existing users: They already know right side is editable and this tip is unnecessary. Also, we are giving side by side editor experience for settings similar to diff editor. In such a case it has to be obvious that LHS is read only and RHS is editable. So, my opinion is remove the header help tip and bring some affordance. By removing this, UI looks much cleaner and simple like Option 3.

2. Option 2 has better advantage than Option 1 by showing a setting's default, user and workspace defined values at the same time. We can also add some kind of user affordance to represent a setting is overridden. It works well when all three (default, user, workspace) can be seen simultaneously. User is free to minimize the user/workspace settings and the choice can be remembered by the editor.

So, from UI point of view I like Option 3 (Clean and Lightweight) and from functionality wise Option 2 is better. I would prefer to have a mix of Option 2 and Option 3.

How about Option 2

• without help tip on the top,
• Affordance to say LHS is default settings and is read only
• Any other UI adjustments to make internal settings editors connected to main workbench editor.

What do you think?

[sandy081]

Another functionality which was missing in above designs is - Ability to search settings across Default and User/Workspace settings. One reason to extend Search bar to complete editor is to search settings across.

Considering all these, I have prototyped following

This has all advantages and also fixed most of the issues discussed above. Let me know what do you think?

[sandy081]

@bgashler1 I have discussed with @bpasero about all designs and also technical feasibility. Bottom line is that workbench is not currently ready to show user and workspace settings files in single main editor (it is true with all above designs). Showing them in single editor is a big step and it can lead to many discussions like, Show a merged version of settings, and also we do not know if it can scale if we get more settings files. We already planned to implement file/language specific settings in this milestone which might introduce new concepts like new files.

Hence we felt to have a simple and step by step solution: Show a link to workspace settings inside settings editor that will open work space settings in a new editor just like now. For eg: see following screen shots

OR

Clicking on Open Workspace Settings link will open it in a different new editor.

[bgashler1]

Thanks for all your feedback, @sandy081! Good thoughts.

Since it's technically not feasible today to do the tabs to switch between "User" and "Workspace" settings in the same editor, could we fake it by making that blue link button look like a tab? Would it be seamless enough of a transition to open another settings.json such that it would look/feel like you just clicked a document tab?

Here's an updated set of designs based on your feedback about the search box and the read only side.

1) Grayed out background conveys readonly

2) Top-right annotation and padlock icon conveys readonly

Additionally, we could make the cursor be the default arrow and not a text cursor.

[bgashler1]

Some other questions to consider as well...

• Should hovering over any part of a setting (and even its comment above) highlight the setting line?
• On mouseUp on a setting should we popup the code actions menu (i.e. you can click anywhere, not just the lightbulb)? (We wouldn't show the popup if a user moves the mouse away or selects text).

[chrisdias]

👍 on the grey background on the left editor to convey 'read-only' if possible.

Personally I like the blue button, but we've already gone down the path of a floating green button (keybindings, debugging) which I feel is out of place from the rest of the product.

Along the lines of what Brad is suggesting above, even if we don't want it to look like a "tab" it could just be a link that says "Open Workspace Settings". I would prefer this simple model over introducing a new blue button.

[sandy081]

👍 on the grey brackground to indicate it is readonly. Liked it.

Faking tabs is a good idea but let me try and see if it is possible. If this works, then your initial options 1a and 1b might also be feasible :). But, I liked the latest one with grey background and one feedback is how about showing a dropdown instead of tabs here? This will have good space utilization and scales well.

We are still missing a header or a title or something to indicate that LHS is Default Settings.

Following are good suggestions and I will consider them

• Should hovering over any part of a setting (and even its comment above) highlight the setting line?
• On mouseUp on a setting should we popup the code actions menu (i.e. you can click anywhere, not just the lightbulb)? (We wouldn't show the popup if a user moves the mouse away or selects text).

[bgashler1]

Cool, thanks guys!

We could certainly use a dropdown if there were going to be several setting files to choose from. I believe tabs or the hyperlink will be easier for the two files we have today, since it requires only one click to switch between them.

@sandy081 Let me know if you need any other mockups/changes. Looking forward to trying out your work when you have it pushed to Insiders :)

[chrisdias]

👍 on getting this into Insiders and removing the prompt about User and Workspaces settings!

[sandy081]

@bgashler1 I pushed the settings editor layout changes to master today. New changes has following

• Extending the search to whole editor
• Tabs to switch between user and workspace settings

NOTE:

• I am not indicating the LHS as read-only as the bg color might not work in all themes. Also, doing this, might raise a question for all read only editors
• We would still need to provide a title for Default settings on the left. Let me know where is the best place to show that?

[seanmcbreen]

It's great to be able to move between Workspace and User settings with ease.

As an aside is there a reason on Windows we don't have a keybinding for User settings. I realize CMD+, is common for almost all MacOS apps but I think having a keybinding for settings on Windows/Linux would make them easier to refer to (in docs, In Twitter, In the new welcome experience, ...).

And now we have a switcher in the editor for work-space and user having just a single keybinding (for user settings) would make sense.

Clearly the downside is taking over a keybinding for a less common task - but it's a critical task and we already do it on MacOS.

[bgashler1]

@sandy081 nice work.

As far as the title for the default settings, I vote that we leave it out unless we have indications from users that it's needed (perhaps we could try it first without it). However, here is an idea for a dismissible header.

Here was another read-only concept I had (but I think the darker background is more clear). Just showing this as another example. I think we could do without it, since you're right it might raise questions on other editors that are read only.

[bgashler1]

In summary, I think we're at a good state here on UI, and I don't think we need to do anything above I just posted.