Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guidelines for additional output parameters #66

Open
bernt-matthias opened this issue Oct 5, 2021 · 3 comments
Open

Guidelines for additional output parameters #66

bernt-matthias opened this issue Oct 5, 2021 · 3 comments

Comments

@bernt-matthias
Copy link
Contributor

In a recent (short) discussion (galaxyproject/tools-iuc#4006 (comment)) we were wondering what's the best way to choose which outputs a tool should produce:

  • multiple booleans
  • one select

Wondering if we should try to standardize this in the IUC guidelines?

For me a select is favorable for the following reasons:

  • its more compact (except for one output)
  • one can contrain them, e.g. requiering at least one (min="1") or requiring exactly one (type="radio")

Here is how the two options look:

bool
select

Maybe add thumbs up/down reactions to the issue if you support/not support standardization... or add comments with arguments.

@bernt-matthias
Copy link
Contributor Author

bernt-matthias commented Oct 5, 2021

Copied from: galaxyproject/tools-iuc#4008 .. Comments from there were

@bgruening: I prefer the multi-select.

@wm75: One disadvantage of the select is that you cannot provide separate help/command line args for the options (as visible in the screenshots).

@wm75: Also, restrictions on the select can only be enforced in the command section (after the user hits Execute). So it's not very clear what the allowed combinations are.

@wm75 It's also easy to abuse the one select box like e.g. here:

Screenshot from 2021-10-05 12-19-51

Clearly the VCF or BCF output is the main output of Delly, while the other two are optional outputs. The single select box doesn't convey that at all.

@wm75
Copy link
Member

wm75 commented Oct 5, 2021

Thanks @bernt-matthias for copying over the comments.

To be clear, I'm +1 on using a select box to deal with all optional/secondary outputs of a tool in most cases.
Just saying that it might be hard to standardize.

@bernt-matthias
Copy link
Contributor Author

@wm75: One disadvantage of the select is that you cannot provide separate help/command line args for the options (as visible in the screenshots).

That's true

@wm75: Also, restrictions on the select can only be enforced in the command section (after the user hits Execute). So it's not very clear what the allowed combinations are.

I guess one or more validators should also do the trick. But the user still only gets the feedback after pressing execute .. I think.

To be clear, I'm +1 on using a select box to deal with all optional/secondary outputs of a tool in most cases.
Just saying that it might be hard to standardize.

So we might just make it a preference?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants