Activity bar - tools activity

[bgruening]

Was part of #17284 and has evolved now ... :)

tl;dr

We're planning to improve how users find and use tools in Galaxy by simplifying the tool panel and improving the tool search. Here's what we need to do (in parallel):

1. Add tags to tools
2. Allow admins to define tags for tools (similar to edam-mappings)
3. Improve the tool browsing page using tags and ontologies, and encourage users to favourite/star tools
4. Clean up the Tools Activity Bar and remove the long static list:
   • Load the toolbox asynchronously for faster rendering
   • Show only favourite and recently used tools

---

🧪 New Tool Panel (Activity Bar)

The updated tool panel should be minimal and user-focused. It should help users find tools they need — without showing them the full, overwhelming list.

The panel should include:

• A search field (with tag-based suggestions)
• A link to the full tool list page (current tools advanced search results page)
• A list of the user’s favourite tools
• (Optional) A list of recently used tools based on local execution history

If the user doesn’t have any favourites yet, the panel should guide them to the full tool list to start exploring and starring tools.

---

🔍 Tool Search

Typing in the search box should give smart suggestions. For example, typing samtools could suggest:

• tag:samtools
• starred:samtools
• and all matching tools

Similar to how GitHub search behaves.

---

🧰 The /tools/list Page

This page should become the main place to explore / discover Galaxy tools. It needs to be improved by:

• Supporting advanced filtering (similar to workflows list) using tags, tool metadata, and ontologies (like EDAM)
• Making it easier to find and star useful tools
• Giving a better overall UX for browsing

---

🏷 Goodbye Sections, Hello Tags

Tool sections have been hard to maintain for admins and are not very useful for search and less useful for tool discovery, we think they should be replaced completely with tags to gain more flexibility.

To help with this, we can:

• Add a new XML component for tools:

  <tags>
    <tag>text</tag>
    <tag>cut</tag>
  </tags>

• Or maybe allow a simple comma-separated list.
  • Enable admins to define tags in a config file, e.g.: tool-id<TAB>tag1,tag foo,tag baz,tag4

Future enhancements

We think that communities (of practices), subdomains or Galaxy labs, could offer an options to "import" a community curated "starr pack". For example if you are interested in single-cell, the SPOC community is offering a curated set of starred tools (and maybe workflows) that a user can import and start with.

[ahmedhamidawan]

remove (starred) workflows from the tool-sidebar

We could then move starred workflows to a quick access scroll list in a WorkflowPanel (which should not have the advanced search for workflows as it does now...).
If we don't want that:

• we'd obviously need to find another place for starred workflows (or not, if we're ok with them only being filterable in the workflow grid?),
• and we should also just remove the WorkflowBox (workflow side panel) which currently has an advanced search (which is not needed since we already have that in the grid; clicking the activity would then only route you to the WorkflowList).

make tool categories (EDAM etc) more obvious

One idea is to show the EDAM id(s) as tag(s) in the panel, for e.g.:

Would be interesting to try to fit multiple EDAM tags though...

display (1) to go to the advanced search of all tools

Here is my comment on how we could change where the advanced tool search goes:
#17283 (comment)

[ahmedhamidawan]

Thank you for updating this issue with these nice ideas @bgruening ! I'm sure there will be developer discussions where we can finalize on the overall direction.

I personally like all of the ideas here! My comment above and the comment it references falls in line with the proposed changes to the advanced search results, which I had also proposed should turn into a separate tools grid. This was on my radar for quite a while.

The tool search recommendations idea is also very cool! I wonder if it would be nicer to use the little badge we currently use for fuzzy search already?:

Or whether it's just nice to use a dropdown autocomplete/datalist (like GitHub search). Just brainstorming... 🧠

For the other points, it would be helpful to split this into different, parallel mini-projects.

[bgruening]

The tool search recommendations idea is also very cool!

Nice idea, but I think this should be in addition. What I was after with the "Tool Search" is that people still can search for "a group of tool" - that is all tools tagged with "foo". And that we do that very convenient. I think this is a different use-case to fuzzy search and we should have both :)

[mvdbeek]

Thanks for updating the issue, we should definitely take this into account when we prioritize the next round(s) of work on the roadmap.

A tool browsing page might be an interesting improvement, 👍 and the search enhancements are in line with how the advanced search works today.

• Add a new XML component for tools:

I don't think we should update tools for this, and I think preset tags might often just not be applicable. I already grind my teeth every time I see workflow tags like GTN or various incantations of PairedEnd, PE, Paired end, Paired-end etc ... that don't mean anything, and if we hardcode them in tools that will be even harder to remove and ignore. We barely make use of edam tags (which at least have an objectively defined meaning) in the UI, I would perhaps start with making those more useful ?

we think they should be replaced completely with tags to gain more flexibility.

We have tool panel views now, is there something missing in terms of making them work for you ?

Load the toolbox asynchronously for faster rendering

It is async, but I assume you want to replace the large API response without which we can't start rendering ? This would deserve some more thought and planning.

I see that @ahmedhamidawan assigned himself, but he is also working on a lot of high priority and important things, like invocation error reporting, restructuring the queries that we make in the invocation view, modernizing the frontend <-> backend interaction in workflow related code, a proper structure for managing invocations, longer term working on the history graph view. I would much prefer if those things were addressed first.

[bgruening]

• Add a new XML component for tools:

I don't think we should update tools for this, and I think preset tags might often just not be applicable. I already grind my teeth every time I see workflow tags like GTN or various incantations of PairedEnd, PE, Paired end, Paired-end etc ... that don't mean anything, and if we hardcode them in tools that will be even harder to remove and ignore. We barely make use of edam tags (which at least have an objectively defined meaning) in the UI, I would perhaps start with making those more useful ?

EDAM ontologies are used and will be used hopefully more if they are actually visible and if you can tinker around with that - in the tool browse interface.

However, EDAM is community specific, life-science for example, and I think we need a way to broaden this.
I completely agree with you that the entire community will never agree on one terminology, but there is also no need to do so imho. IUC can define a set of tags, or IUC says do not use tags at all. However, you might want to aggregate tool into something like "all samtools" ... for those we can use tags and lower the admin burden.
Tags also do not need to be shown very prominently, it might be enough to search for them. I think we should try this, and more metadata does not hurt if the community finds them useful.

Btw. part of the proposal is a way to overwrite certain tags etc. for certain tools. The same concept will also enable a smooth transition from categories to tags.

Another way to think about it ... we already force tool others to add categories to shed.yml file, which are completely out of sync with what is deployed in Galaxy. Defining this as part of a tool, or at least make sure the tool carries this "tag" around so users can search for it is another benefit. In sum I think the tag system is just way more flexible (which can fire back if you pointed out), but you can also have the current user-inferface just with the tags and have a more coherent deployment process and finally similar / identical tool-boxes in major Galaxy instances.

we think they should be replaced completely with tags to gain more flexibility.

We have tool panel views now, is there something missing in terms of making them work for you ?

No, categories simply do not work, I think. They maybe had when the tool set was 100-200 tools, but not if you have 4000 tools. The panel is not good for browsing, it is good for searching.

Load the toolbox asynchronously for faster rendering

It is async, but I assume you want to replace the large API response without which we can't start rendering ? This would deserve some more thought and planning.

Yes. Don't render all the stuff that one single user never touches.

I see that @ahmedhamidawan assigned himself, but he is also working on a lot of high priority and important things, like invocation error reporting, restructuring the queries that we make in the invocation view, modernizing the frontend <-> backend interaction in workflow related code, a proper structure for managing invocations, longer term working on the history graph view. I would much prefer if those things were addressed first.

The priorities' discussion is complicated, I don't want to go into this direction here :)
I'm happy to pull in resources from Freiburg to get this done to make some users and admins happy.

[ahmedhamidawan]

I see that @ahmedhamidawan assigned himself, but he is also working on a lot...

I think this can be broken down into multiple projects. For some of the items here (esp the minor UI enhancements), I reckon most of us will agree with for the most part. In that way, I think there can absolutely be multiple assignees and/or we can even create multiple different issues.

As far as priorities go, again, some of these things are relatively minor (like the ToolList view which I've wanted to modernize/grid-ify for quite a while) so I think they can be achieved in the current cycle.

[mvdbeek]

However, EDAM is community specific, life-science for example, and I think we need a way to broaden this.

we talk about EDAM because that's what we use in practice, but nothing in our infrastructure binds us to EDAM. We can deploy our own custom ontologies, that had been the goal in supporting a no-config deployment that emulates the current section system.

all samtools

isn't that supposed to be captured by the biotools id ?

No, categories simply do not work, I think.

So that's both a bold statement I might make as well (😅), but also aren't tags just a different type of category ? Why not define stuff like that in the panel views ? This seems like a path that is easier to implement and maintain. The tag-in-tool approach seems to have some obvious downsides:

• updating a tool to update the default tag seems very bad
• Can't agree on the presence or absence of a tag, now what ?
• I don't think the answer is overriding this in a server config ... and what if your users disagree ? This in particular you can cover with tool panel views.

you can also have the current user-inferface just with the tags and have a more coherent deployment process and finally similar / identical tool-boxes in major Galaxy instances.

how would that work, short of an option in the galaxy config that lets you ignore all tags ? as soon as you install a tool you like that has a nonsense tag it's game over, no ? I don't think the answer should be that now you've got to maintain tag overrides.
it seems that people are enthusiastic about labs and subdomains and such, isn't that the right place to invest energy into ?
Then you can chose a template or maintain your own.
If you do want to pursue this I would definitely appreciate a more detailed planning document that also says a few things about alternative approaches.

The priorities' discussion is complicated, I don't want to go into this direction here :)

That's fine, but it does need to happen.

[bgruening]

Before I try to answer to your questions inline, let me ensure you that I think ontologies are useful and we should use them. I think they get more powerful in the tool-discovery view. I also think tags can be misused and we should not extensively use them. In this proposal we can use tags as a means to give more power to people outside Bio* and in addition they will provide us a nice migration path away from sections.

However, EDAM is community specific, life-science for example, and I think we need a way to broaden this.

we talk about EDAM because that's what we use in practice, but nothing in our infrastructure binds us to EDAM. We can deploy our own custom ontologies, that had been the goal in supporting a no-config deployment that emulates the current section system.

If you want to develop an own ontology please do, I will not stop you :)
I hope other communities will do that and will add there ontology to Galaxy at some point.

all samtools
isn't that supposed to be captured by the biotools id ?

You mean:

• https://bio.tools/samtools_idxstats
• https://bio.tools/samtools_filter
  or https://bio.tools/samtools_sort :)

Even if we could and would do this, we are restricted to bio* ... and yes we are working on making bio.tools more broad to other communities - since 5 years ;) it takes its time.

No, categories simply do not work, I think.

So that's both a bold statement I might make as well (😅), but also aren't tags just a different type of category ? Why not define stuff like that in the panel views ? This seems like a path that is easier to implement and maintain. The tag-in-tool approach seems to have some obvious downsides:

😅 haha. I usually don't do bold statements in public ;)

See this 12 years old thing: 94cc2dd

People are complaining about sections since at least 13 years to me, and they still do. I put considerably time and effort to maintain them.
And see above for more arguments, like non-sync tool panel across Galaxy instances etc ...

also aren't tags just a different type of category

Yes, but way more flexible. In the main description of this issue, I also stated that the tags are used to migrate away from sections. So our old sections become tags. Tags are just more flexible, not 1-2 dimensional. You can mix and match them in the tool-browse interface.

* updating a tool to update the default tag seems very bad

Yes, nothing I would recommend, but doable if a particular community decides so. Like the imaging community that agreed on a unified way to "name" tools.

* Can't agree on the presence or absence of a tag, now what ?

The same what happens currently if people can not agree on the tool name or tool description - or EDAM terms etc ...

* I don't think the answer is overriding this in a server config ... and what if your users disagree ? This in particular you can cover with tool panel views.

We do the same for EDAM terms, bio.tools IDs, containers etc ... It was not a problem so far, its an option, it rarely used, but it gives us a nice migration path - from sections to a more flexible system.

you can also have the current user-inferface just with the tags and have a more coherent deployment process and finally similar / identical tool-boxes in major Galaxy instances.

how would that work, short of an option in the galaxy config that lets you ignore all tags ? as soon as you install a tool you like that has a nonsense tag it's game over, no ?

The same as bio.tools, EDAM, tool name, tool description ...

And again, I'm not saying we need to display tags in the tool-panel. They enrich your search-space. It provides you with more options to get your tools found - to favorite them and create your own tool box - in the tool-browse interface.

I don't think the answer should be that now you've got to maintain tag overrides. it seems that people are enthusiastic about labs and subdomains and such, isn't that the right place to invest energy into ? Then you can chose a template or maintain your own.

Subdomains / labs have been created by EU first, and guess what one reason was ... sections are problematic.

If you do want to pursue this I would definitely appreciate a more detailed planning document that also says a few things about alternative approaches.

This is this issue. You are welcome to contribute alternative suggestions. We have tried over the times so many things to make sections work, after 13 years its time ... at least for the big instances to let them die.

If you insist, we can make this an optional tool panel, that admins can default too.
I can only speak about EU, we spent so much time on managing sections etc and talk to users, that we want to get rid of them.

Tags are a minor thing in this proposal, if you don't want them we can start with the other stuff and then we don't have a migration way. Fine by me.

[mvdbeek]

tags are just more flexible, not 1-2 dimensional. You can mix and match them in the tool-browse interface.

I guess this is my point of contention and why I would like to see a slightly more detailed plan. You can add tools to all the sections that you consider appropriate (via the main toolbox or tool panel views). The UI that having tags would enable could use a mockup or a description of a user story.

Subdomains / labs have been created by EU first, and guess what one reason was ... sections are problematic.

I understand that, and seeing things you'll never interact with is a big issue there I think. More limited tool boxes is one of the cool things afforded by labs, and #20716 might be a way to streamline the user interaction and funneling more users into that direction. The panel views as they are present today are a little hard to discover and maybe that'll lead to more use ?