Design: Preferences Layout

[slemeur]

Is your enhancement related to a problem? Please describe

The layout / styles and sections in the preferences need to be reworked.

At the moment there are the following challenges:

• The sections are difficult to identify
• Some of sections are "settings and configuration" of the tool itself, some other are "user preferences"
• It will be hard to scale with the future options we might be adding

Describe the solution you'd like

• We may need to consider introducing a "Settings" section in the left sidebar (main navigation) for some of the main settings for the application (registries, resources and in the future, proxies, volumes, secrets).
• Each of the provider (podman, crc and other) may need to contribute certain specific settings too
• We need to make it clearer/easier to navigate in the different preferences
• We may need to consider using lists for the "extension catalog" section and the different "machines" from podman.

Describe alternatives you've considered

No response

Additional context

No response

[gbengaoti]

Beginning with how the preferences/settings page should open, I have made a sketch in FIGJAM

https://www.figma.com/file/FkfUo7A97j8TXWwonsOtSp/Preferences-section

Essentially, when the user clicks on settings, a new page should be opened

[gbengaoti]

With regards to the configuration settings, I have made some sketches in FIGJAM on what I think they should look like. However, I am still unclear on the content that needs to be presented to the users. Some feedback on these sketches would be helpful: https://www.figma.com/file/b6wXhPl49jRI9aJJVtqkND/configuration-settings

[slemeur]

Thanks @gbengaoti ! The proposed layout approach works well!

Question:

• should we differentiate application configuration (managing podman machines, resources) from user preferences (display options)?

I think the next step would be to look at creating patterns that we can reuse across different sections. The proposed solution from @mairin with tiles for registries could be a nice option, but I'm worry it might not be applicable for all kinds of configurations and we may need simple list.

As @mairin pointed out, it's going to be important to allow creating/editing without using a 3rd level of modal too.

[gbengaoti]

Thanks, Steven, the user preferences are currently called preferences on the main settings page but the label can be changed to make it clearer.

Have you had a look at the configuration page, are you happy with the structure and the content of it? Please let me know

Yes, unifying the UI of the application would be good

[mairin]

Two inital options here.... top has a tree, bottom does not.

I'm concerned about ordering... some of these seem more core than others - what I did in the tree one is pin the "Preferences" category to the top and the rest are in alphabetical order by top level name. I can't make out rhyme or reason for how the order of how they display in vscode so that wasn't much inspiration.

[benoitf]

I prefer option 1 but it may take more to implement

About the way to update values, when is it done ? each time user change a character ?
About choosing files, for now user click on the field and it brings a dialog to select a file/folder. Should the rendering contains a browse... button so bring that dialog or from UI/UX it's ok to behave like that.

[deboer-tim]

Visually I prefer 1 as well, my only worry is whether the two columns on the left will take up too much space on small screens (but maybe that's not an issue).

My preference for most properties is to have them apply immediately. I wonder if we'll want a 'reset to default' on some?

[benoitf]

reset to default would be nice (we know which properties have default values)

[deboer-tim]

I had a Slack chat with someone asking about preferences redesign, and they preferred the first option as well. They suggested the second tree could be merged into the left nav - which is essentially where it is today. I'd second that, or say that with only ~8 prefs today we could fix the rest and defer the decision of whether to add nav directly onto the page.

[mairin]

Awesome thanks for the feedback! Here's the points I'm taking away to think about:

• I was thinking instant apply would be best for this screen - I surveyed preferences dialogs like this across a bunch of tools and most have instant apply... there were a few situations where they're a little more transactional and queue up any changes and have a global "apply" button with a notification "you have unsaved changes", but the latter seemed like a lot of complication without too much payoff. I think instant apply is simpler; I'm not an expert in implementing it but I think a common way of triggering it is to save after the field loses focus. So you don't have to call save on every single character press and you have some idea the user is finished typing.
• For responsiveness of the treemenu - we could make it disappear in narrow window situations, or merge into the main nav under Preferences like you suggested @deboer-tim ... I'll mock this up and see how it works.
• I'll add reset to default buttons!
• I'll add browse buttons for paths - I think this is a good idea @benoitf!

[mairin]

I forgot to update with the new mockups! The changelog for these is basically in the last comment: #183 (comment)

Opt 1 Main nav tree merge

Opt 2 separate tree

I believe during the UX review meeting we had a preference for opt #1.

[mairin]

This is already implemented 😅 Closing!!