Replies: 2 comments 5 replies
-
|
Hi there @jl-beast . If I'm understanding correctly, by "old styling" you mean the simpler form which only displayed the relevant fields (ie. had a fewer number of fields displayed)? Or do you mean something else related to the layout? @antgamdia Was the main reason because we don't have access to the simple form schema any more and so are generating the form elements automatically? Although the UX still seems to be displaying only certain fields - on what basis is it showing certain fields and not others? I'm asking because I'm keen to understand if, with future custom values provided by users, people might still be able to replicate the old simpler forms, or is that no longer possible? |
Beta Was this translation helpful? Give feedback.
-
|
@jl-beast, first of all, happy to hear the Kubeapps' "basic forms" feature is being useful for your company; but, conversely, I'm sorry the new UX is not working for your team. This new UX comes to solve an inherent problem to how the old basic forms worked: we were using a custom, non-standard, In this new situation, we no longer have a subset of a manageable number of parameters, but a set of hundreds of parameters. The old UI was simply non-functional (response times increasingly high, like 20-30 seconds) and the UX when having plenty of params was really poor (endless scroll til you find the param you're looking for). We decided to go with a simpler design, just a filtrable, paginated table containing all the params; containing both the default and deployed values at a glance. We've lost the conditional render of the params (like, "ey, hide this subsection if this param is false"), but we are now fully aligned with JSON Schema, meaning we can use the expressivity JSON Schema has to build richer experiences. In Kubeapps 2.6.0 we just performed the change, but we are keen to work with our adopters to bring those important features for them. If the problem is the number of params, there's a hacky solution to prevent it from happening: Kubeapps v2.6.1 brings a "schema editor" under a feature flag ( In short, we are keen to know which features your team is missing in the new UI so that we can work to improve it, as unfortunately, we aren't providing a way to bring the old UI back (we indeed deleted the outdated code). Hope this clarifies our reasons to drop the old UI, but, as I said, we're keen to know more and work towards the improvement of the new one. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, had an old comment and recognized that I misread something... deleted it to adjust and simplify. Given that the Bitnami Application Catalog is going to auto-generate the json-schema, would it still be possible to provide your own values.schema.json? And in such a case could you still support the forms feature for the purpose of rendering some sort of "Form Editor" similar to the old style? Basically, for our organization, it was very simple and easy to boot up instances of various applications based on a form-based layout. The new layout acts less of like a guided tour, but rather an advanced tabling of all our fields. For QA people who might need to customize some YAML fields in order to conduct some testing of our apps, this new UI makes it very difficult for them to quickly set things up. Something like a "Form Editor" using old UI styling similar to forms and reading from the provided values.schema.json (with the ad-hoc forms field) would be much appreciated. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the excellent description, both @antgamdia of the clear background and @jl-beast of your use-case. I'm currently investigating the ability to add both custom values.yaml files as well as custom form schemas, as part of #5560. So that would be the issue to track. The plan would be to enable per-repo-chart custom values and forms that can be set by the operator of Kubeapps, but it's in the early stages at the moment and there are a few other changes going on, so I can't guarantee anything yet, unfortunately. |
Beta Was this translation helpful? Give feedback.
-
|
@absoludity Appreciative for you guys to take my consideration and use case in mind. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @jl-beast, this is Pepe Baena, engineering manager at Kubeapps. As a Kubeapps adopter, I’d like to feature your organization in the ADOPTERS.md file. Would you like to be included? We only need a PR with your logo and 1-2 sentences describing how your organization uses Kubeapps (we can also help you with this PR). I really appreciate it for promoting Kubeapps use cases like yours throughout our amazing open-source community. |
Beta Was this translation helpful? Give feedback.
-
|
I have discussed with members of our organization and we are grabbing some stuff and will see about making a PR. Thanks for the outreach. |
Beta Was this translation helpful? Give feedback.
-
As a part of the organization that I am a part of this, we use Kube-Apps as a means of managing our cluster and conducting testing.
Many engineers much preferred the older UI styling as it was relatively quick and easy for non-engineers to fill out fields and boot up instances for doing things like Demos.
I was wondering if there would be a way to revert to the old styling? I am not aware of all the various challenges and reasoning on the UI changes, but the current UI is causing quite a few groans.
Beta Was this translation helpful? Give feedback.
All reactions