remove rule to use select for conditionals

[bernt-matthias]

The UI/UX group wonders if this rule is justified, i.e. are there any studies saying that it is not a good idea to have a boolean control optional parts of the form.

Problem: we are enforcing this rule for a long time via IUC guideline and linter rules. Changing the booleans to selects is error prone and requires downstream workflows to be changed.

See also xref galaxyproject/galaxy#18759

[martenson]

My guess is that the decision was something along the lines of "let's pick one of the two to unify the interface"

[mvdbeek]

I would assume that the reason is https://github.com/galaxy-iuc/standards/pull/78/files#diff-b4d7a25bc189ff4f4394b214449058fc46226ea3ec53b09f8fe66c2e4b566e4dL245-L246, which also needs adjustment @bernt-matthias.

There's plenty of examples where booleans control available options, apple does this extensively on iOS. I don't know if consistency is worth the extra clicks to see and then select the available options if we've got a boolean with just 2 options.

[bgruening]

I don't know if consistency is worth the extra clicks to see and then select the available options if we've got a boolean with just 2 options.

I do think that consistency is great for our users. You can annotate a select param more than a boolean param and help users more ... e.g displaying more information about the 2+ options ... more than just Yes/No. In addition, we will always have conditionals with more than 2 options, where we need a select param. So why not be consistent here in our Interface Guidelines?

Having clear guidelines is I think what this repo is trying to do and what IUC should do. Ofc not everyone needs to follow that, in the end its just recommendations.

Problem: we are enforcing this rule for a long time via IUC guideline and linter rules. Changing the booleans to selects is error prone and requires downstream workflows to be changed.

I'm questioning this motivation a bit.
It's a very specific problem of a few old tools. Most of our tools fulfil this requirement.
It's not a new problem, those few tools have failed our linting for many years.
If we do not want to change those specific tools, ok, let's just ignore those and their linting warnings. 1) just merge them or 2) ignore lint errors per tool.

The argument is not compelling enough for me to sacrifice consistency here.

[mvdbeek]

These are good points and of course there are uses for selects, however the points you mention also apply to boolean's outside of conditionals, and we don't think those require a linting rule.