Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide GUI for settings #3355

Closed
Tyriar opened this issue Feb 23, 2016 · 81 comments
Closed

Provide GUI for settings #3355

Tyriar opened this issue Feb 23, 2016 · 81 comments
Assignees
Labels
feature-request Request for new features or functionality on-testplan settings-editor VS Code settings editor issues ux User experience issues
Milestone

Comments

@Tyriar
Copy link
Member

Tyriar commented Feb 23, 2016

Customizing Code would be far less intimidating to new users if there was a GUI for settings customization.

@Tyriar Tyriar added the feature-request Request for new features or functionality label Feb 23, 2016
@mrmckeb
Copy link

mrmckeb commented Mar 1, 2016

I'd like to jump in and work on this, as I've heard the same thing from others. Are there any design guidelines or references, @Tyriar?

@felixfbecker
Copy link
Contributor

I also think this would make more people adopt VS Code. Here are some ideas:

  • Similar to how you can switch between markdown code and preview, allow to switch between the settings.json file and a GUI, with the GUI being the default
  • Dynamically generate the GUI from the JSON schema, including those from extensions
    • booleans become checkboxes
    • arrays and hashes become lists were it is possible to add / remove new items
    • numbers become spinners
    • strings become input fields
    • union types?

@Tyriar
Copy link
Member Author

Tyriar commented Mar 1, 2016

@mrmckeb not yet. But speaking of which, this would probably need to go through UX first. ping @bgashler1

@mrmckeb
Copy link

mrmckeb commented Mar 3, 2016

Thanks @Tyriar. Perhaps I could start work on the functionality here and we could polish the UX later? The approach would be something similar to what @felixfbecker described, and I also like how the Atom team manage their settings.

@bgashler1 bgashler1 added the ux User experience issues label Mar 3, 2016
@bgashler1
Copy link
Contributor

Nice idea. I previously had a similar idea, and I agree this could be be less intimidating to new users. It could also beneficial to people who don't know JavaScript and who are using VS Code for another language that doesn't have anything like JSON. Finally, JSON can be unforgiving if you miss a comma or closing brace somewhere.

The worry the team had when I shared this idea previously was that a GUI would not be able to do everything JSON could do as simply and effectively. JSON is leaner (you copy just what you need and change just what you need); it's easy to see what you've changed, because you're only overriding defaults. Intellisense also helps people write what they need. Lastly, JSON results in shareable recipes that can be committed or emailed to others.

Despite the drawbacks, @felixfbecker, you have an interesting idea of generating the GUI based off of JSON—with some careful styling and layout rules, this could work well potentially.

@mrmckeb you mentioned that you've heard this from others. Could you point me to that discussion?

@bgashler1
Copy link
Contributor

Google Chrome settings seems like a good source of inspiration since they filter through a mass of settings based off of keywords.

@bgashler1
Copy link
Contributor

@mrmckeb Before we jump into implementation. Let me first check with the team and also get some mockups to be sure we have the experience right. I would hate to waste any effort before we have the experience where it needs to be.

@egamma
Copy link
Member

egamma commented Mar 4, 2016

I like the discussion, but we hear different feedback on this topic:

image

@mrmckeb
Copy link

mrmckeb commented Mar 5, 2016

@bgashler1 I've heard in a literal sense, in my office. I don't have a discussion to point you to sorry. I'd argue that whilst the tweet @egamma has shared is a valid reason to keep the JSON settings in place, it doesn't mean we can't have both - perhaps upon first opening settings, you are given an option as to which way you'd rather proceed?

As the extension/plugin library grows, I'm sure more of the creators of those plugins would also like a settings GUI to tap into (again, Atom has done a great job of this).

I also understand the complexities that are concerning a few people, that maybe the JSON is too complex to auto-generate settings from. The other way to go about this is to specifically create a GUI that's tailored for core settings, and refer users to the JSON for advanced settings - but I really would rather create something smarter and all-encompassing where possible.

If there are concerns about changing the structure of the JSON (which I assume there would be), we could also look at something JSDoc-like for declaring (in comments) what the 'GUI-friendly' name of each setting is, and how it should be displayed in the GUI. Example below.

/**
 * Controls the font family.
 * @name "Font family"
 * @type text
 */
"editor.fontFamily": "",

@felixfbecker
Copy link
Contributor

@mrmckeb You do not need JSDoc, every setting is specified in JSON schema, which allows to specify descriptions, default values and types. An extension can already provide more settings with a schema.

@mrmckeb
Copy link

mrmckeb commented Mar 6, 2016

Thanks @felixfbecker, good point - I didn't realise JSON schema was in use here. That's a far better solution.

@ianwesterfield
Copy link

@mrmckeb I like the idea of a gui, and think @felixbecker has a good compromise to what @egamma brought up because I find updating the JSON to be faster.

Atom's implementation...it doesn't flow nicely. I find either scrolling forever (especially the beautify package), or jumping into each little extension's page and back again to be a clunky, uninspired design.

Not original, but maybe something akin to the tree in Visual Studio? That would eliminate jumping around to different views for extensions and keep scrolling to a minimum.

@iam3yal
Copy link

iam3yal commented Mar 13, 2016

Personally, I don't like GUIs for options at all, I really wish for the day that Visual Studio will have its options stored in a JSON file too. :)

@mrmckeb
Copy link

mrmckeb commented Mar 14, 2016

@ianwesterfield I agree that some of what Atom does could be tuned, and hear both you and @eyalsk. I understand completely that many people prefer to update JSON settings, and can see why.

I'd never propose doing something that alienates part of the community, but I believe that the current approach is alienating some users. It would be great to find a strong compromise here.

There are advantages to both approaches. JSON is fast, explicit, searchable, and easy to manage/share. The GUI allow for intuitive controls, understanding without reading documentation or comments, and the ability for some magic (i.e. automatically disabling setting y as it relies on setting x to be enabled).

The right approach might be that the first time you open the settings JSON, you're prompted and asked if you'd prefer to use the GUI. We could keep data on usage of each, and if the GUI becomes more widely used, we'd default to that instead - but keep the first-time prompt in place.

Again, I'm trying to finds a solution that impacts both parties the least - let me know if you have any better thoughts here, it'd be great to keep this discussion going.

@ianwesterfield
Copy link

@mrmckeb I agree, I think some discussion should happen whenever there is a possible user gap.

I vote for @mrmckeb's idea for a prompt when first opening the settings.

I also agree that whatever the gui looks like, it should be generated automatically by the default JSON, and it's settings persist to the user's JSON as they reside today.

@felixbecker had two great points earlier in this thread.

I assume the same would go for keybindings to keep things consistent?

@iam3yal
Copy link

iam3yal commented Mar 14, 2016

@mrmckeb I don't mind to have a GUI as long as it's a separate application and in fact I think it should be, someone can just pick it up and write a GUI application for VSCode and a simple extension to launch it via tasks. :)

If you are really serious about making a GUI that people will actually use then generating it automagically from the JSON file is not only a bad idea but you turn a simple problem to a much larger one that I'm not sure you understand.

P.S. I'm all for discussing it, sorry if I hijacked the post with my objection to it.

@felixfbecker
Copy link
Contributor

@eyalsk the nice thing about JSON generated GUI is that it makes it easy for extensions to add settings that get a GUI aswell.

What do you think about my suggestion where the settings.json just has a button like the Markdown preview button that switches to settings UI?

@ianwesterfield
Copy link

@eyalsk I'm afraid I don't really understand how this could become a much larger problem. Perhaps you could elaborate?

I wouldn't expect a user to go find some other application just to manage the settings. That's weird in this context. Can you name other IDE/document editors that manage their settings this way?

@iam3yal
Copy link

iam3yal commented Mar 14, 2016

@felixfbecker The issue with what you are proposing where you exchange text with controls is that I'm not sure how great the experience would be and I'm not sure what you gain by doing it.

So without an actual UI I see no point in it.

@ianwesterfield

I'm afraid I don't really understand how this could become a much larger problem. Perhaps you could elaborate?

Okay, if you refer to the kind of GUI @felixfbecker proposed then I guess it wouldn't be so hard to do but I don't see much value in it but maybe I'm wrong. :)

I wouldn't expect a user to go find some other application just to manage the settings. That's weird in this context. Can you name other IDE/document editors that manage their settings this way?

The person can simply make it available as an extension, when the extension is executed for the first time it grabs the installation and install the application and finally start the application, the second time it just starts the application but the bottom line is that it's not so different than installing any other extension so it certainly not weird.

The VSCode team can make this available by asking the user whether he wants a GUI to manage the settings so the user wouldn't have to find it.

The benefit of making this as a separate application is that it loads as part of a separate process.

@bgashler1
Copy link
Contributor

Here's a proposed look of GUI settings. Special thanks to @felixfbecker for your idea that I incorporated in this design.

  • It works similar to markdown preview.
  • You can click the "Preview" button on the top of the header for the GUI.
  • You can get to a particular setting or category of settings the same way as you do in JSON, by using + f or ctrl + f.
  • As you update settings in the GUI, they are reflected in the JSON (and vice versa).

gui-for-settings-01a

@felixfbecker
Copy link
Contributor

@eyalsk

The issue with what you are proposing where you exchange text with controls is that I'm not sure how great the experience would be and I'm not sure what you gain by doing it.

The benefit is easier discovery of settings. Currently, you have a) the default settings where you can discover what settings are available and b) the actual settings.json. You always have to copy+paste the settings or use IntelliSense. In a UI you can see what settings are available, see what values they have and change them at the same place.

So without an actual UI I see no point in it.

I don't get this, there would be an actual UI.

@bgashler1 this is near to how I imagined it, a few complaints though:

  • the headlines need to be smaller
  • true / false should simply be a checkbox
  • I find it a bit weird that the UI opens over the default settings and still shows the actual settings side by side. It would make more sense if you toggled the view of the actual settings.json to get the UI, and then maybe automatically close the default settings json window.
  • What should happen when you set a value back to the default value? Should it get removed from the settings file?

@pflannery
Copy link

@bgashler1 That is looking good so far. Just keeps it simple.

  • The size of the text and radio button look right for people with disabilities. Maybe size could be tailored for preference but default to big so new starters to vs code with disabilities can jump right in.
  • I think using radio buttons for true and false is spot on because their best for choosing a single option in a list, where as check boxes are best for opt-in opt-out lists.

Be cool to have a search filter to quickly get to each configuration from inside or outside of the settings file, it could also hide non-relevant settings too.
Also categorization for things like theme overrides and extension settings would be wonderful.

I've never liked the way ide's have handled their preference gui's. I've always felt removed from the actual environment I'm working in and to top it off I'd always find a crucial area of configuration stuck in a horrible little single line text box. (:cough: :cough: just like (the old) Microsoft Windows Env Path editor in system properties).

@iam3yal
Copy link

iam3yal commented Mar 15, 2016

@felixfbecker

The benefit is easier discovery of settings. Currently, you have a) the default settings where you can discover what settings are available and b) the actual settings.json. You always have to copy+paste the settings or use IntelliSense. In a UI you can see what settings are available, see what values they have and change them at the same place.

Okay, you make some fair points here.

I don't get this, there would be an actual UI.

Yeah, what I meant by that is that exchanging text with controls might not be as intuitive as a custom made GUI and might be somewhat limited.

Don't mind me though @bgashler1 did a great job so I'm looking forward to see this in action and try it out. :)

@bgashler1 well done! mate.

Paths might be tricky to determine because there's no convention but maybe you can check whether the key ends with .path or Path and replace it with a file input instead of a textbox.

@mrmckeb
Copy link

mrmckeb commented Mar 15, 2016

Looking great @bgashler1. When do you expect to get sign off on the design?

I think the technical side of things should be manageable, but as a few people (like @eyalsk) have pointed out - we need to make sure that the JSON translates into a GUI as seamlessly as possible. @felixfbecker's earlier JSON Schema suggestion seems like it would cover this.

My feedback/thoughts:

  • There could be a Windows-style settings search/filter, where it effectively filters the settings shown as you type. There's a lot of whitespace, but I think that fits with the design of VSCode..
  • There's a lot of whitespace. This isn't necessarily a bad thing, but could make the GUI quite long - especially as people start using more extensions with their own settings.
  • Has there been much thought to how extensions would be handled in settings? Would it literally represent the JSON structure? Or would it highlight extension settings vs app settings?

@Tyriar
Copy link
Member Author

Tyriar commented Mar 16, 2016

@mrmckeb afaik this is just exploratory and we're not committing to anything yet. The main concern of most people seems to be wasted effort in building out this when it's not adding any new real functionality, just an alternate UX. It could also potentially be more confusing have two different editors for the same thing.

Extensions are another beast which would probably need to be handled quite differently. I created an issue for that too #3356

@pflannery
Copy link

@mrmckeb I wonder if a prototype of @bgashler1's example could be started now by using a similar technique as @egamma pointed out to @drywolf #3011 (comment)

Then later on down the line it could be migrated to a json viewer extension if and when it becomes available (i.e. like the current markdown viewer).

@mrmckeb
Copy link

mrmckeb commented Mar 17, 2016

Sure @pflannery, I can take a look at this over the weekend and see what I can get done.

@mrmckeb
Copy link

mrmckeb commented Mar 20, 2016

@pflannery, sorry I didn't get a change to look at this over the weekend. I'll try to look one night after work this week, but if not, definitely on the coming weekend.

I'll obviously need to get my head around developing VSCode and it might be slow to start with, but I'm really excited about jumping in.

@Tyriar I'm sure whatever work is done here will be somewhat transferrable to that too (at least in part).

I can see the competing ideas here, and both sides make valid points. I feel that the argument around discoverability does make the GUI option compelling, but understand the need to implement this in such a way that power users could get away with never seeing it.

Personally, I don't want to have to research what each setting does or what options are available. I also see the value in having those settings in JSON so that I can store them with my projects, or synchronise my settings between computers.

If this idea did end up being an extension, I'd hope that it would be something that was an option during the install process. That could be a good compromise, example below:

Would you like to use the GUI for changing settings? Selecting yes will install the extension settings-gui, which can be removed.

@roblourens
Copy link
Member

  1. Table of contents - we have discussed this. We might end up with something like that but it does seem to add a lot of visual noise. Also our categories are not all user-friendly and we think searching is more useful than browsing categories at the moment.
  2. Done, thanks for the suggestion ✔️
  3. Underlined because it's a link, but the UI is a work in progress
  4. I removed the dot because some people confused it for the "unsaved" file indicator. But it's also good to not rely only on color differences for important UI indications, for accessibility reasons. The "Reset" button only appears on configured settings, maybe that+the color are enough for now.

@logar16
Copy link

logar16 commented May 27, 2018

I was turned off to VS Code when first introduced to it because there was no simple GUI for picking colors for the theme or syntax coloring. That's the first thing I change when I get an editor. So several months later I started looking into VS Code because of good reviews. So, my experience shows that you'll get more of the beginners in if you make it easier. But leave the option for those hardcore individuals who'd rather do it all in JSON.

@gandalfsaxe
Copy link

I have the opposite problem now - is there any way to open settings.json directly, instead of:

  1. going to settings
  2. click ellipses
  3. click "Open settings.json"

@pastudan
Copy link

pastudan commented Sep 9, 2018

@gandalfsaxe I reassigned the keybinding of Ctrl+, to workbench.action.openSettingsJson, as this keybinding was the default for opening the settings.json before the update. Easier than even navigating the file menu in my opinion.

I do think the new settings dialog should do a better job of highlighting the option of using the awesome settings.json editor, rather than hiding it behind an ellipses menu. Perhaps even give an easy option to make it the default for power users.

@roblourens
Copy link
Member

There is a setting for it, workbench.settings.editor

@pastudan
Copy link

pastudan commented Sep 9, 2018

@roblourens ah, just noticed after reading the release notes :)

I guess my point was around highlighting that option in the settings UI. The settings.json editor is an immensely powerful feature that a new user would never know about.

@gandalfsaxe
Copy link

Yeah I'm also using a shortcut for workbench.action.openSettingsJson now:

Mac: ctrl+cmd+,
Window: ctrl+alt+,

@reeddunkle
Copy link

The setting takes a String value of "json":

"workbench.settings.editor": "json"

@vscodebot vscodebot bot locked and limited conversation to collaborators Oct 13, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature-request Request for new features or functionality on-testplan settings-editor VS Code settings editor issues ux User experience issues
Projects
None yet
Development

No branches or pull requests