add tool tips on partner icons

[FynnBe]

Small suggestion, it would be nice to have the name of the software as tool tip on each partner's icon, what do you think? Not a priority at all of course.

Originally posted by @ElpadoCan in bioimage-io/collection#104 (comment)

[cfusterbarcelo]

In my view, displaying the name on the list might look a bit redundant since many community partner icons already include their name. Additionally, when you click on an icon, the name also appears at the top, which provides clear identification. As an alternative, we could adjust the "Start Exploring" function to apply a filter that shows only resources related to the selected Community Partner. How does that sound?

[ElpadoCan]

To be honest, when I suggested a tooltip I didn't even realise that the name was displayed on the top and it was because my scrollbar was to a level where the top part was not visible.

So the only "problem" I see is about clicking on a partner icon when the top part is not visible (because scrollbar already scrolled down).

However, I don't have a solution for this (except for the tooltip but I agree it's redundant in normal situation).

For example, if I click on any community partner in this situation not much happens which is a little bit confusing.

[esgomezm]

Hi there! @ElpadoCan is right. At the moment, when placing the cursor on top of the icons, the name does not appear anymore (@oeway ?). Additionally, the search function is broken when clicking on the icon. When you click on any of the icons, searching for apps or models with that tag is impossible, you need to type it manually.

[FynnBe]

I don't think we need to avoid redundancy here. IMO tooltips would be a nice addition.

There is some filtering (via types I believe?) happening, but yes, the differences are marginal, which is not ideal. Adding filters, ideally based on compatibility check results, would be great!
To this end I propose to add tags "ilastik-compatible", "biapy-compatible", etc. I would reserve these for the generated compatibility checks, i.e. remove them if not applicable, but set by the uploader. Inspecting the diff between tagged with "ilastik" and tagged with "ilastik-compatible" could be a valuable insight for tool maintainers to identify models expected to be compatible that are actually not.

A partner configuration could specify if the partner view should filter by those compatibility tags or (the default) the simple "ilastik", "biapy", etc...
This would lead to a concise view of relevant resources for any given partner and clear differences between these partner views.

(I might be disregarding existing, but buggy partner filtering)

[esgomezm]

Hi Fynn, it'd be super super nice to automatically tag after the CI. Yet, could we also add the "ilastik" or "deepImageJ" automatically to those models that are meant to be compatible? For example, deepImageJ deploys models with format tensorflow's saved_bundled model, trochscript, and eventually onnix. If none of these formats is available, then, the tag shouldn't be there. This type of "requirement" could be defined in the CP's description

[FynnBe]

@esgomezm am I understanding correctly that you are suggesting to overwrite (add or remove) the tool tags ("ilastik", "deepimagej", etc) based on CI compatibility checks?

note: When I write "overwriting" here I'm only thinking of the tags we report in the collection.yaml summary that the website uses to render the collection etc... not overwriting the content of individual rdf.yaml files, these should not change based on software changes external to the resource itself (e.g. a new ilastik version now supporting this model...).

I can see that you'd like a third category in addition to "passed" and "failed" that is essentially "should pass, but doesn't".
I think this status is difficult to set automatically -- any rule we'd come up with will have its exceptions and thus be misleading...
If we have one manually set compatibility tag (e.g. the plain tool "ilastik") and one that is generated for passed compatibility checks ("ilastik-compatible") the difference is basically the "should pass, but doesn't" category, no?

Btw, we should probably also add version specific tags, e.g. "ilastik-1.4-compatible"...

[esgomezm]

If we have one manually set compatibility tag (e.g. the plain tool "ilastik") and one that is generated for passed compatibility checks ("ilastik-compatible") the difference is basically the "should pass, but doesn't" category, no?

Yes, this is what I meant. My suggestion came from yours. One of the issues with manual tags is basically that contributors and actually everyone, forget about tagging the models with compatible software, and even notebooks that were used to train the model and export it, or can fine-tune it. For example, there are models sometimes tagged with Ilastik but not with deepImageJ. In theory, the statement "should pass", could come simply from the weights' format (which is what it's used to download the models). That's why I was thinking that tags could be automatically generated in the way you clarified:

note: When I write "overwriting" here I'm only thinking of the tags we report in the collection.yaml summary that the website uses to render the collection etc... not overwriting the content of individual rdf.yaml files, these should not change based on software changes external to the resource itself (e.g. a new ilastik version now supporting this model...).

About the category "should pass, but doesn't" I'm not that sure because it's basically if it passes the CI or not, but I don't have a strong opinion on this one

[FynnBe]

ok, to move forward on this for deepimagej specifically we need to move on bioimage-io/collection#82

[ElpadoCan]

I'm not sure I understood correctly, but should every community partner have a CI workflow set up? How is a compatibility check performed typically? Should we discuss this in a dedicated issue maybe? Thanks!

[FynnBe]

Yes, whenever feasible a community partner should have compatibility checks in place.
How this is done is described here
I did mention it in bioimage-io/collection#104 where it is an open todo.

[oeway]

@FynnBe the tooltip get lost because of the CI.

it need a name field, please add it back when you generate the partners list:

{
            "background_image":"static/img/zoo-background.svg",
            "default_type":"model",
            "explore_button_text":"Start Exploring",
            "id":"deepimagej",
            "icon":"https://raw.githubusercontent.com/deepimagej/models/master/logos/icon.png",
            "logo":"https://raw.githubusercontent.com/deepimagej/models/master/logos/logo.png",
            "resource_types":[
               "model",
               "notebook",
               "application"
            ],
            "splash_feature_list":[
               
            ],
            "splash_subtitle":"A user-friendly plugin to run deep learning models in ImageJ",
            "splash_title":"deepImageJ"
         },

[FynnBe]

oh sorry, I have overlooked the name field when creating the Partner representation
fixed: