Every filter tool that includes a "genome regions" input could be made more user friendly

[jennaj]

Example here at GHelp: Filter SAM or BAM tool -- "Select regions" filtering term formatting

Maybe have the tools remove extra spaces the users add by accident? Or give some message in the output dataset's expanded view about what filter region term was actually applied (not great -- why isolate for one filter when many were applied)? Listing out all applied is not practical, some tools allow for lists of regions to be input (and those could be screened for obvious format issues as well...). To complicate it, some allow more than one region to be entered, but the formatting is standard.

We should be able to tell/fix what is wrong with formatting in many cases -- unless completely off/unusable == give a good error message.

If decide to do this, can work out best approach. "Free text" entry by the end user can have all sorts of problems .. tools shouldn't ignore those and fix what they can, and give an actionable error message when cannot.

A not super high priority issue, but would just make tools easier to use. Comes up every so often. Does not result in an error but certainly could be trapped (more than one contiguous "term" in the entry box detected, instead of just parsing out the first). Maybe just a better error message (fails silently now, parsing the first "word" of the term, and just applying that to the filter). See the Ghelp post for details for one highly used tool.

This touches many tools. Maybe can prioritize using tool error rates, etc.

cc @jmchilton

[wm75]

Maybe of interest: my latest iteration of the chromosomal regions problem in the GEMINI query tool (see on eu: https://usegalaxy.eu/root?tool_id=toolshed.g2.bx.psu.edu/repos/iuc/gemini_query/gemini_query/0.20.1).

The Region Filter there breaks down the complex free text into separate chromosome, start and end fields, which get joined together again by the wrapper to give the format the specific tool requires (a rather complex part of an SQL query in that case).

Does that look reasonable to you?

[wm75]

In particular, you can define start and end to be integer parameters so invalid input will be detected before job submission. You can also omit start and/or end, but not the chromosome identifier and, again, the missing identifier will be caught before execution.

[jennaj]

@wm75 Yes, that is GREAT. All tools with that entry could use the same change

[jennaj]

We had talked about doing something like this for vcftools filter as well (also has free text for complex terms). I probably have a ticket for that, am looking just to link it all up.

[jennaj]

Three tickets actually. Breaking out the query into distinct entry boxes would address all of these in one go:

galaxyproject/tools-iuc#2389
galaxyproject/tools-iuc#2388
galaxyproject/tools-iuc#2387

cc @jmchilton @dannon what do you think of this approach? across all tools with free form but structured expression text? eg: break the term down into different entry areas

[jennaj]

and would make changes like this one (done) unnecessary
galaxyproject/tools-iuc#2385

[jennaj]

gonna cc @VJalili because he worked on that vcfilter tool

but I don't want to focus on a particular tool. this could be a tool dev "best practise" type of change. very good for users!