Change Advanced Tool Search to a Tool Discovery View

[ahmedhamidawan]

We've discussed the idea of moving the advanced tool search out of the tool panel, and into the "search results" view for a while. It makes sense because the advanced search, which searches via the backend, is decoupled from the client search which applies to the panel itself and is entirely client side.

Therefore, we've moved the filters to the center panel in the rich tools list view, and more work will be done on making this view the best place to find ideal tools for our users' analyses.

This implements part of the plans in #17286

tool_discovery_view_3.mp4

Initial Implementation...

tool_discovery_view_2.mp4

How to test the changes?

(Select all options that apply)

• I've included appropriate automated tests.
• This is a refactoring of components with existing test coverage.
• Instructions for manual testing are as follows:
  1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

• I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

[ahmedhamidawan]

Some action items, credit to @bgruening :

• Instead of showing EDAM id, the badge should show the real underlying term - so a user understands
• Remove Section from Section: XXX badge
• Do not show "(Galaxy Version N.N.N)", maybe show this in a clickable popover
• ^ Along with workflow compatibility badge (which can maybe also be entirely hidden from users?)
• Remove owner badge (keep filter though). Maybe I can add that to that same popover with the above 2? 👀
• Bring the Favorite Tool button front and center, needs to be the MAIN ACTION in this tool discovery view. Note: I did it by adding "Add to Favorites" text to it to make it bigger. Open to any more suggestions!
• For not logged in users, hide disable the favorite tool button on tools as well as and remove the one next to filter field
• Add a share tool button
• Remove the PanelViewMenu from this view, and do not make section and EDAM dropdowns dependant on that. (This might mean we will enforce fetching the 2 EDAM views always
• Remove All tools loaded from this view: I think I will make that a conditional in ScrollList and allow to show total count for all results when they're all loaded
• Also, do not show currently loaded count (Loaded 80 out of 14974 tools); same thing, add that prop to ScrollList
• Allow to open tool in another tab (via Ctrl-Click)
• Nothing happens when you click run on a tool that has form_style !== "regular"
• Try to sync search with route Will need to see if this is performant, given now every time the search value is changed, the tool helps are fetched again!
• Add an "Explore Ontologies" view. Button on top right, breadcrumb heading, view that shows ontologies in GCard view, each clickable to apply filter.
• Add easy way to "reset/clear" the section or ontology drop-down
• Copy ontology ID to clipboard on badge click
• Fix: The pop-over of "What are EDAM Ontologies?" has 100% width
• Ontology view is very slow to load, maybe paginate it too

Some potentially hard to resolve or complex action items:

• "Loaded 100 out of 14788 tools" this is wrong ... we should not count versions. Users probably don't care here in this view about versions. A tool - the latest version is what counts - IMHO.
  • There is an interesting question that we should discuss: Is the search, searching all tools with all versions, or only the latest? I would be in favor of just the latest version - to cut improve performance. - @bgruening

Follow-up action items:

• MAJOR: Use an entirely new backend search framwork other than Whoosh? It just doesn't seem to return well ordered results.
• Allow multiple ontology filtering
• Currently, if there is a #favorites filter, no other filter applies. Make it possible to filter within favorite toolset.
• Make favorite tools sortable (update time etc filtering, but also manual reordering)? This view could allow users to easily reorder their favorite tools as they prefer, so next time they want to quick-run a tool via the panel, they have their preferred/most-used tools at the top?
• Add a github like search with datalist-esque key:value recommendations
• Add a "Recently Used Tools" view
• Highlight interactive tools in this view more: "can the card border maybe have different colors for interactive tools and data_sources (the workflow incompatible tools)?" - @bgruening

Point for discussion

• Should we use the GCards (implemented in the workflow, history, invocation scroll lists) as opposed to the current ToolCard headers used here?

Resolved! 🎊: We are going with the GCards

[bgruening]

This is an awesome improvement, thanks a lot @ahmedhamidawan. It works nicely in my testing.

[ahmedhamidawan]

Thank you @bgruening ! Just checking out these tests locally, should be unrelated but double checking still...

Update: Ran locally, should be fine. The GridList jest and other integration failures should be unrelated to the changes here