You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As shown in the example below, a couple of small things slightly hinder the user experience when configuring a service before launch:
The title and description fields from the values schema files are meant for documentation and not user interface definition. As such, they are often defined in a more verbose or redundant way than is preferable in our context.
The configuration structure is naturally inherited from the values.yaml which is sometimes a bit too deeply hierarchical whereas forms are usually more linear. The Custom box, below, for example, doesn’t add much value to the interface.
The vertical margins: it's nice to have a well-spaced interface, but with the various top banners, it forces a lot of scrolling and prevents getting a quick overall view of the form.
My suggestions (up for discussion):
The title and description fields may be defined in Onyxia catalogs to better fit the needs of a user interface. However the resulting values.schema.json file would then be hard to read or reuse in a different setting. Instead it could be useful to provide alternatives for these (rightfully) descriptive fields. For instance:
{
"title": "A precise field title",
"description": "An exhaustive description",
"x-onyxia": {
"title": "Short title",
"description": "Extra info in subtitle or empty string to hide"
}
}
Move the longer description into a tooltip (a small icon that would display the text either on click or hover in a mini-popup) rather than a smaller font subtitle. Short description could be kept inline, as they are now. The display mode could also be controlled in values.schema.json:
As shown in the example below, a couple of small things slightly hinder the user experience when configuring a service before launch:
title
anddescription
fields from the values schema files are meant for documentation and not user interface definition. As such, they are often defined in a more verbose or redundant way than is preferable in our context.values.yaml
which is sometimes a bit too deeply hierarchical whereas forms are usually more linear. TheCustom
box, below, for example, doesn’t add much value to the interface.My suggestions (up for discussion):
title
anddescription
fields may be defined in Onyxia catalogs to better fit the needs of a user interface. However the resultingvalues.schema.json
file would then be hard to read or reuse in a different setting. Instead it could be useful to provide alternatives for these (rightfully) descriptive fields. For instance:values.schema.json
:Below a suggestion of a target interface that, in my opinion, would be more usable while remaining precise enough for new users.
The text was updated successfully, but these errors were encountered: