Zowe Config Web View

[adam-wolfe]

Starting a discussion around the work started in #3656 to implement a graphical team config editor/utility as part of Zowe Explorer.

Please feel free to share any ideas or things you would like to see changed or added to the tool.

[davenice]

Thanks for starting this conversation @adam-wolfe, and thanks for looking at the work, @jace-roell.

I think that broadly the most common issues I've seen from customers have been:

• Struggling to get the right nodes in the right structure (profiles node, hosts nodes etc)
• Struggling to know how to get started adding a connection into the file - a CICS node appears but it's not all that obvious that it's your connection to edit, it's just a big JSON structure.
• Editing the structure of the file (sometimes accidentally!!) can result in favourites disappearing
• Ending up with not very good structures (like all connections listed separately without a base profile, or without using nested profiles)

Are there other end-user issues that you are addressing with this? Do the ones I've listed resonate?

As well as internal users, I had a conversation with a business partner who is an educator and has experienced their students finding it harder to get started - I'll give them a link to this thread and ask if they have any further pain points.

I think for the structure issues and getting started, it might be helpful to shepherd users down a path "you're creating a connection? should it share properties with another connection?". I can see scope in the prototype to add in validation and help prevent users from accidentally breaking the file structure, which would be nice.

[davenice]

[Reposted so I'm not replying to myself!]

Do you have a set of scenarios in mind, or a vision for how this would pan out in the future?

I'm happy to continue a discussion on here or to have a call which we minute if that would be a productive way forward.

A thought around look and feel is that users are used to the VS Code settings panel. Although this can't sit within the settings, taking inspiration from the over style and design would be good. However I think it would be great to have a consensus on what we're solving before getting too far into the look and feel :-D

[JWaters02]

Just want to add my two cents. The current way it's been shown in the standup a few weeks ago where the UI looks like the config JSON file, I think does not really solve the problems Dave mentioned above where it difficult to understand what the "correct" settings should be. My feeling is that the UI should be driven by the schema file and should be entirely decoupled from how the JSON actually looks. The more it looks like an actual configuration page and not just a JSON file but with fancy styling, the better. That way the UI/UX designers from wherever can design something user friendly (I definitely feel this is a mammoth UI design task and will likely require mockups in figma/similar tools to figure out how it should work).

It also should take into account the types of each property (i.e.. enum, string, bool, int) and provide UI elements based on them (i.e. dropdown, text field, checkbox, spinbox).

Also, I think there should be some kind of "validation" functionality. Ideally the UI should be designed where entering in a property that does not exist in the schema is not possible, but if not, the user should be able to click a button that validates the config file (which is already a functionality that exists in ZE where a popup appears) and most importantly, highlights which part of the config is invalid in the UI itself.

I have some ideas about how it could work/look and might make some figma mockup to present my ideas if I have the time to. But I think this will indeed require a lot of discussions and will take a lot of time to get right, especially considering what a complex beast the config file is. I do not think this is a thing we can release half-done/not thought through completely as it should either work well or not at all to avoid sowing a great amount of confusion into the configuration process.

[JWaters02]

I decided to get the ball rolling with a first mockup that is not a fancy JSON editor. Read the text around the outside of the mockup to get extra info. And you need to fill in some of the blanks about how other stuff would work, but I think it's at least a step in the right direction.

I also believe that we need a way to onboard new users when creating their config file. This could be done by:

• Having some kind of "wizard" like setup of the first profile types that has a lot more info and goes step by step. This would have the benefit of being able to be designed with exclusively newbie setup to be as easy as possible, i.e. would probably not need support for extenders or nested profiles as that is considered an advanced feature.
• Creating a vs code walkthrough (which allows highlighting of parts of the UI with dialog boxes) of the config UI that provides the same lots more of info as above. This would have the benfit of not having to design and maintain two seperate webviews and would also allow all users, not just newbies, to remind themselves of all the workings of the config files.

[GerMFHub]

I'd like to add a few additional points to this discussion:

1. Difficulty editing the JSON configuration file:
   Users often struggle to correctly define multiple sessions — for example, connecting to different servers with different user IDs. The current setup isn't intuitive, especially for users unfamiliar with the structure of the config file.

2. Invalid edits cause silent failures:
   If the JSON file is edited incorrectly, it often can't be saved, but there’s no clear error message pointing to the specific issue or line. In some cases, a user might accidentally type something and then be unable to save the file without understanding why.

3. CLI prompt writes to incorrect locations:
   I've encountered cases where a user runs a TSO command from the Zowe CLI and follows the interactive prompts to enter account, port, and other connection details. These settings end up being written to the wrong part of the JSON file, resulting in broken or invalid configurations.

[JWaters02]

Screenshot of current state of zowe config editor PR for reference

[JWaters02]

Could we perhaps get some example configs that utilise all the different features the configs support and some scenarios that may work? For example nested profiles, profiles for different LPARs with different userids, etc.

[davenice]

I asked Ross Cruickshank who runs Z Xplore, he said:

The "edit the raw json" is one of the most frequent source of problems. Most of our users are new to computing, so editing JSON is daunting and error-prone.
Prompted editing would be helpful -- the schema-based validation is good, but the adding things is the killer.

[jt-nti]

I think prompted editing could work well, and is something that already happens in VS Code, e.g. configuring dev container features, or configuring tasks.

A possible temporary solution to the problem of adding things is to use snippets. For example, I've create a zowe.config.code-snippets gist on GitHub which demonstrates how that could work.

That's still not great though, especially for the kind of users Ross mentioned, and in most cases it would be nice if people did not need to edit the config at all. It seems like something that can be shared, rather than asking everyone to create themselves. For example, here's a (commented) zowe.config.json for Z Xplore which could be used as is.

Another option which goes a step further is to use predefined dev containers, where you don't even need to worry about where to get the config from at all. For example, in my Z Xplore dev container I've been experimenting with setting up the config file using zowe config commands and a json file for the nested/parent profile.

[davenice]

Hello all,

At the latest Zowe Explorer scrum we agreed to run a design workshop in the Zowe Explorer scrum on the 1st July (so 4pm-5pm BST).

The meeting schedule is here: https://zoom-lfx.platform.linuxfoundation.org/meetings/zowe?view=week
I think the exact meeting Zoom link should be: https://zoom-lfx.platform.linuxfoundation.org/meeting/91415795361?password=d8c984c6-3ea6-46e2-ba9d-1ff13a436430

We plan to consider what the user requirements are, how these scenarios feel to a user with the existing tooling, what the options are for implementing solutions that improve these scenarios (building on the work done by Jace, Joshua, and the suggestion from James).

We will use a Mural board to allow everybody in the meeting to contribute their thoughts and ideas. This will require specific email invites. Please get in touch if you'd like to participate.

[davenice]

@GerMFHub - in case you're free and interested to participate.

[jace-roell]

Hello All!

Attached below is a few screenshots of my second draft implementation of Zowe Config Web View. Nothing is final but I figured this would be a good place to leave an update for awareness! Thank you.

[davenice]

Hey Jace, thanks for this. I like the way this feels closer to user concepts than JSON concepts :-)

Also the thinking that you've done so far on how profiles will interact (I am thinking that's what root profile is).

I feel like you've managed to merge yours and Josh's ideas, which is great!

For me I'm still battling internally over the wizard approach (which appeals to me as a long-time Eclipse developer) and trying to make sure I take on the VS Code quick-pick-and-code-editor approach. I think that's a bit of a detail though.

One of the questions I still haven't worked out an answer to is what we would do about base_profile and nested profiles. Do we know what we'd guide people towards and does that alter how we visualise things? I noticed that Joe W suggested that nested profiles were his preference - https://medium.com/zowe/password-management-for-zowe-cli-profiles-c57f64d1fe88 ...

Have you got some learning/thinking about some of these tricky bits that you've had to think through as part of this, that you can share?

[JWaters02]

For me I'm still battling internally over the wizard approach (which appeals to me as a long-time Eclipse developer) and trying to make sure I take on the VS Code quick-pick-and-code-editor approach. I think that's a bit of a detail though.

I really think we should avoid using quick picks for config editor. Configs are way too complex for quick picks which are only meant to be for setting a small number of values in succession. I also think config editing should not involve any code editing as at that point you may as well just change the config json directly.

As for wizard approach, why not both? Both wizard for first time or more "walk through/tutorial method" setup and a general "overview" UI config editor.

Thanks a lot for posting Joe's article, I had not seen that before! In fact this is my first time seeing any kind of explanation of what nested profiles are with examples and this makes so much more sense now! Thanks!

[jace-roell]

Hey Jace, thanks for this. I like the way this feels closer to user concepts than JSON concepts :-)

Also the thinking that you've done so far on how profiles will interact (I am thinking that's what root profile is).

I feel like you've managed to merge yours and Josh's ideas, which is great!

For me I'm still battling internally over the wizard approach (which appeals to me as a long-time Eclipse developer) and trying to make sure I take on the VS Code quick-pick-and-code-editor approach. I think that's a bit of a detail though.

One of the questions I still haven't worked out an answer to is what we would do about base_profile and nested profiles. Do we know what we'd guide people towards and does that alter how we visualise things? I noticed that Joe W suggested that nested profiles were his preference - https://medium.com/zowe/password-management-for-zowe-cli-profiles-c57f64d1fe88 ...

Have you got some learning/thinking about some of these tricky bits that you've had to think through as part of this, that you can share?

Hey Dave, thanks for the feedback.

I agree with Joshua in regards to quick picks being a little too simple for the complexities of profiles but I like the idea of having a "walk through/tutorial method" for first time users to have a deeper understanding of the profile types and the authentication methods for each.

When it comes to nested profiles vs base profiles, I personally prefer nested profiles but the current POCs do not push users in any specific direction but I am open to hear feedback/suggestions on a direction to take it. This could also be discussed on a future workshop.

Feel free to checkout the config-web-view-v2-poc branch to see the current state of the POC. Be aware there are many features (deleting profiles, adding types on existing profiles, setting default profiles, etc) that are not implemented and im sure there are plenty of bugs to iron out. If you do find any bugs, feel free to message me on slack. Thanks!

[jace-roell]

Hey All! Just wanted to leave another POC update.

I have added some features that are subject to change but exist to give an idea on what it could look and feel like! These features include, previewing merged arguments for a profile, setting defaults, rendering defaults, deleting profiles, etc. These changes currently exist on the same branch (config-web-view-v2-poc).

As mentioned before, feel free to reach out if you run into any bugs 😅. Thanks!

[FALLAI-Denis]

Hi,

I don't know if this is the right place to discuss this, but Zowe profile management must take into account how RACF (or TopSecret) works in a sysplexed z/OS partitions environment:

• a RACF database manages credential validation (and resources access)
• a RACF database can be shared by multiple z/OS partitions linked in a sysplex: the same credentials will be used across all partitions in the sysplex

So, in a Zowe profile, there is credential management, and for 1 credential, it may be necessary to declare 1 to N z/OS partitions, and for 1 z/OS partition it may be necessary to declare 1 to N Zowe profiles.
The construction of a zowe.config.json file, and hence the GUI for updating this file, must take this reality into account.

Furthermore, the names of Zowe profiles (which are entered in Zowe CLI commands or in Zowe Explorer configuration) should not be impacted by the organization of the zowe.config.json file: no level1.level2.levelX.name to name a profile. Most often we want to have a name that corresponds to the z/OS partition accessed, plus possibly a prefix or suffix related to the protocol used.
See:

• Zowe CLI V2 - Independence between profile name and internal organization of the zowe.config[.user].json file

Thanks.

[Rajat-Sahrawat]

Hello,
This is my first go at the config editing experience. This is just the editing experience and representation of nested profiles for now, I thought I'd share it here for some feedback.

config.editing.ui_1.mov

I realised I forgot to mention in the video about deleting a property, here are those screenshots:
Hovering on a local property

Hovering on an inherited property