Apps available section doesn't do anything

[zrthxn]

The "Apps available" section on the homepage doesn't do anything. The app icons don't take you to the page related to the plugin and the down-arrow button doesn't open more plugins.

Expected Behavior

• The icons should open the page related to the plugin.
• The down arrow should either open a list or take you to the /plugins page

[Aaishpra]

Hey, @zrthxn will you be working here? if not I would like to get assigned.

[zrthxn]

The maintainers haven't yet confirmed that they want this fixed or that they agree with the expected behaviour. If they do then you could.

[Aaishpra]

@jennydaman can you confirm the issue and implementation part, so that I can submit a PR.
Thanks

[jennydaman]

Sorry for the silence. @zrthxn do you want to work together with @Aaishpra on this? If not, better to let @zrthxn have it as he is the author of this issue.

First, we need to brainstorm a bit. Should these icons be the latest uploads? The most popular plugins by star count? Or hand-picked by an admin? Depending on how you want to do this, it might be a full-stack effort — requiring backend features to account for extra data.

Also, a problem is that most of our plugins do not have icons because

• us devs are too lazy
• there is currently no good way of uploading an icon

I've discussed this in our slack channel #chris_store_frontend. Join the conversation!

[zrthxn]

Yes we could work together on that after we've discussed how to proceed.

Should these icons be the latest uploads? The most popular plugins by star count?

I think it's better to have the most popular plugins by star count since that makes more sense and it's easier for the backend as well (I think). I wouldn't mind also working on the backend features needed for this (if any).

[Aaishpra]

I guess I would let @zrthxn be assigned to this issue, as I am already working on other issues. But would definitely like to coordinate by giving my suggestions for this.

I agree with @zrthxn about displaying the plugins by most popular star count but displaying hand-picked plugins by an admin can be a very beneficial feature in long run (maybe some plugins are not that popular but the admin wants them to be introduced first )although it can be a future implementation feature after we can successfully implement the first one.

[jennydaman]

By star count works great.

[jennydaman]

Relaying a discussion from Slack:

Current block on this issue is poor support for plugin icons in the ChRIS_store backend design. Neither do we have any icons which actually give icons because of the poor support.

We are proposing a new backend feature to support icon upload and static hosting. Better icon support by the backend would have the implementation of front-end features like this one make more sense.

[mairin]

Hey your friendly UX designer chiming in here :-)

So the intention with the list of 5 icons was they would be hand-picked, high-interest / well-known plugins to entice developers to list their plugins and make it very quick and easy to click to the most popular icons for ChRIS Store users.

Also I can create icons for whatever needs an icon.

[jennydaman]

You're right, hard-coded is not an evil in all cases.

@mairin, about icon design: some of the popular 3rd-party software have icons, but they're ugly (FreeSurfer, FSL, ANTs)

Regarding software which exists in the ChRIS store that fits "high-interest / well-known", I know of (because I made)

• https://chrisstore.co/plugin/78
• https://chrisstore.co/plugin/77

Fitting "high-interest" (machine learning, has publications, first-party)

• https://chrisstore.co/plugin/71
• https://chrisstore.co/plugin/72

I might want to make some icons for those two for some inkscape practice...

[jennydaman]

Recap: this issue #125 is a duplicate of #102, and there is an open PR #124

A good implementation of this feature depends on backend updates:
FNNDSC/ChRIS_store#44

@mairin you have said that the featured plugins should be "hand-picked." But what about for thid-party instances of the ChRIS_store? For example, the plugin pl-ANTs_N4BiasFieldCorrection exists in chrisstore.co but it might not exist in a private chris-store.som.neu.edu.

I can imagine a ways forward:

1. the hand-picked plugins are hard-coded to link to plugins in https://chrisstore.co, our global, first-party instance.
2. the hand-picked plugins are defined by a configuration file that is part of the build script.
3. the deployment at chrisstore.co should be off of a new branch, say prod or chrisstore.co, and not master
4. instead of hand-picked plugins, feature the plugins with most stars

[mairin]

@mairin you have said that the featured plugins should be "hand-picked." But what about for thid-party instances of the ChRIS_store? For example, the plugin pl-ANTs_N4BiasFieldCorrection exists in chrisstore.co but it might not exist in a private chris-store.som.neu.edu.

2. the hand-picked plugins are defined by a configuration file that is part of the build script.

This is what I would suggest. Because different ChRIS stores might have different focuses, if it turns out we have an ecosystem of different ones. For example one may focus just on tools for neuroscience, another might focus on tools for (just throwing something out there) orthopedics. So the admin would want to highlight the tools most relevant to the theme / field at hand. I think doing that via a simple config file (maybe a list of the plug ids to display) would be the most drama-free way to do that so I like suggestion #2 the best.

[jennydaman]

See #150