Missing title field in JSON schema for plans

[pkosiec]

The title field is missing in plan schemas fields. It's good to have it, especially if some uses front-end libraries for displaying forms from JSON schema.

I've used a few solutions for React and Angular and all of them displays title as label - for example, https://github.com/mozilla-services/react-jsonschema-form. It fallbacks to object key name, so it results in a rather ugly form:

I'm working right now on a pull request that introduces titles for all fields for plans.
Hope you'll like it 🙂 Cheers!

[krancour]

@pkosiec thanks for the issue (and the PR).

I'm open to discussing this change, but still feel a bit reluctant.

My rationale here is that while you may perceive fallback field titles that match parameter key names (e.g. resourceGroup or sslEnforcement in your example above) as ugly, I actually see them as ideal because they are the true parameter names. I probably feel that way because I (selfishly) care most about the experience for users like myself who work without a GUI and the current behavior makes the GUI experience as similar as possible to the non-GUI experience. (i.e. Parameter names are the same.)

Also note...

There are some existing GUIs that work with our broker (and other brokers, too). For instance, OpenShift and KubeApps. Whether it is for better or worse, I'm going to guess that adding title to input parameter fields in the schemas will affect how forms are displayed in those existing products. I'm not keen to change behavior under the feet of existing users.

At the end of the day, as I said, I'm open to discussing this change, but I don't want to rush blindly into merging it.

I'm going to delegate some decision on this to @seanmck.

[pkosiec]

Hi @krancour, thanks for your answer!

Generally, in my point of view, GUI should be an abstraction for an user. If he uses GUI, then he shouldn't be bothered with parameter names etc. All labels should be clear, concise and in readable form. But I understand your concerns. We have different opinion on this topic and that's absolutely fine!

I just would like to have a choice, how to display those titles. This change is an improvement, because it gives an user ability to display label for a field in a different form than just raw object key name.

Adding title field shouldn't break UIs of existing users - if they really mean to use object key names, then it will be fine. It's just an additional field which may be used - but users are not forced into displaying it. In JS library which I am using, it fallbacks to field key name - but it depends on the used solution. Some libraries can simply just don't display titles, when they are not provided. So this change can even improve users' UIs.

[krancour]

@pkosiec suppose the existing GUIs are using the same library as you. (React and Angular are both really popular.) Wouldn't it then be likely that if title is added to each param to make it display differently for you that those other GUIs will also use title by default and no longer fall back on the key as they do today?

Disclaimer: I am not a JS / front-end guy at all. So if the question seems naive, realize that I haven't personally used React or Angular.

[pkosiec]

I know that one React solution does the fallback. One solution for Angular doesn't display label at all, if the title isn't provided. I don't know about others. However, I think this is issue of a developer, if he is not explicitly declare that he want to use key names as field labels.

I've just checked package.json of OpenShift console UI and I haven't found any familiar library for parsing JSON schema, so they are probably doing that on their own (some kind of custom solution).

They also display friendly field labels (not raw object key names):

[pkosiec]

Hi @krancour, any news regarding the issue? Did you discuss it with @seanmck? Thanks!

[krancour]

I think this is sensible. The PR needs a rebase, but after that, g2g.

[pkosiec]

@krancour Thank you! I've just rebased my PR.