Reorganize the Galaxy tool list

[ilveroluca]

The categorization of the list of tools in our Galaxy deployment needs to be discussed and reworked.

• Some tools fit under more than one category, so should probably be put under a ore generic category.
• The tools under W4M should be split into the various functional category
• We should look into the possibility to have tags attached to the tools that can be searched from the search box. An alternative might be to include the tags in the tool name (for instance, in parentheses at the end of the name) so that the search can still work.

[pcm32]

Rachel Spicer, PhD student at our group, came with a classification of tools that we are using for the App library. On Galaxy we have less freedom in the sense that the tree depth can only be one, but we could base it on that. Go to the App library, it is to the left. It is used for filtering, but we could use for ordering the tools. Only issue is that on that scheme one tools can belong to more than one category (is tag based).

[pcm32]

This should also be part of decoupling a base container, that other people can use with other tool choice, with our PhenoMeNal one.

[pcm32]

How do we handle W4M tools and Galaxy-M tools so that it is very clear that those tools come from those providers? Should we have separate Galaxy section for each? or a subsection? My suggestion would be (remember that this is for the Galaxy left toolbar, which only has up to 3 levels; section, subsection, tool):

• PhenoMeNal H2020 Tools
  • MS
  • NMR
  • Fluxomics
  • Ramid
  • Midcor
  • Iso2flux
  • Others...
• Workflow4Metabolomics
  • LC-MS - Preprocessing
  • XCMS.xcmsSet
  • XCMS.xcmsMerge
  • etc...
  • LC-MS - Postprocessing
  • Other W4M subsections...
    • Other W4M tools...
• Galaxy-M
  • Sub-section Galaxy-M tools
    • Galaxy-M tool X
  • Other Galaxy-M subsections...
    • Other Galaxy-M tools.

What do you think?

[pcm32]

Alternatively, we could have a more thematic approach, maybe borrowing from W4M or Galaxy-M categories:

• LC-MS
  • W4M Preprocessing
    • XCMS.xcmsSet
    • XCMS.xcmsMerge
  • Galaxy-M Preprocessing
    • Tool 1
    • Tool 2
  • PhenoMeNal Preprocessing
    • XCMS
  • PhenoMeNal Fluxomics
    • Ramid
    • Midcor
  • W4M Normalisation
    • Tool x
• GC-MS
  • W4M Preprocessing
    • Tool Y
  • Galaxy-M Preprocessing
    • Tool Z
  • PhenoMeNal Preprocessing
    • Tool W

???

[ilveroluca]

Personally, I think we should keep the user's experience as our first priority. The user I figure will be more concerned with the task to be completed than the origin of the tool :-) With this in mind, I think tools should be grouped only by their functional category. To give visibility to the projects that created the tools, how about using a prefix on the name: e.g., PhnMNl, W4M and Gal-M?

That should give you a tree that looks something like this (based on the trees above):

Fluxomics
  * PhnMNl: Ramid
  * PhnMNl: Midcor
  * PhnMNl: Iso2flux

LC-MS - Preprocessing
  * W4M: XCMS.xcmsSet
  * W4M: XCMS.xcmsMerge

LC-MS - Postprocessing

etc...

[pcm32]

I like your proposal @ilveroluca, however I have one practical question. Can we change the label to be shown for each tool? I wonder since we might want to start installing some of these from the toolshed at some point, and they won't include probably the prefix at the tool's label as we want them to have it.

[RASpicer]

I really like @ilveroluca suggestion. I think that this would be the most user friendly possible given the limitations of organisation with Galaxy.

[ilveroluca]

@pcm32, I don't think there's any simple way to change the tool name when installing. Given our controlled environment (when building the container) it might be possible to hack something that does this, but I'm not sure.

[fgiacomoni]

Hi folks, we have a short experience in W4M with tools panel in Galaxy. We experiment many ways and the W4M core team is today's agree to propose something avoiding duplication tools.

[DSchober]

I gree with @ilveroluca to make the main sortal of a Tool hierarchy the main tool function, in the sense also indicating the position in a WF, i.e. pre, post, ... This is simple and rather unpretentious and can hopefully be implemented by us in an ad hoc way for a pragmatic quick solution. But a more formal and ontologic approach would be to apply & re-use ontologies such as EDAM at http://bioportal.bioontology.org/ontologies/EDAM/?p=classes&conceptid=http%3A%2F%2Fedamontology.org%2Foperation_0004 A good example how this is used to categorize tools is available in the general bioinf tool repository bio.tools, i.e. making tools findable (if not FAIR) by standardized descriptions of Input Formats, Operations, Output Formats according to EDAM Terms. Ee.g. for NMRProcFlow: https://bio.tools/tool/NMRProcFlow/version/1.2 (look at the middle colum) or for Metfamily: https://bio.tools/tool/MetFamily/version/1 (which is rather extensively annotated/described) The drawback would of cause be that EDAM tends to provide an overshot on terms and might miss the simple intuitive categories like Pre- or post processing to bin intuitively on a high level.

[DSchober]

There will be 2 UX workshops coming up and I suggest to use these to test and to draw missing required tool descriptors from the endusers.

[DSchober]

Just as a further inspiration, here a screenshot how tools are sorted in Knime... not saying this is the best way to sort :

[pcm32]

@rsalek started as well another issue on this, with a defined proposal #75.

[pcm32]

I think that this has been addressed by current re-organization in Galaxy. Please re-open if needed, will close in the meantime.