We need a nice landing page for when developers log into the ChRIS store. Most developers will only have one or two plugins; my guess is that it will be fairly rare for anyone to have say more than 12-20. So you can design based on a scale of most users having 1-2 plugins.
Also note the team infrastructure of apps that we'll be adding in, in the future. Assume that this infrastructure is in place, for the mockups! Ideally each plugin will be managed by a team, and each team will have at least two admins. This is because you don't want the plugin to only be modifiable by a single person who might not be available at any given time.
OK, here's some ideas for what should be on the dashboard:
A listing of plugins the developer owns - these can be plugins the developer created herself or plugins that someone else created that the developer is a team member of. Whether or not the developer has 'admin' privileges on the team might be something interesting to flag.
Team management - the developer should be able to create a team for any plugin he has added to the ChRIS store. a developer who initially creates a plugin gets admin status for that plugin; when she creates a team for it, she should be able to add additional team members and give or revoke admin status to any other team member. she should also be able to remove people from a team, or invite people to the team. It might be worth thinking about allowing users to request membership on a team and having a developer with admin privs for that team to be able to approve their membership via a queue here on the dashboard (likely would be linked to via a notification email.) Note that github doesn't do this request feature from what i've seen so it's probably not critical.
Statistics about the plugins - whatever we can come up with. It's likely not feasible to provide number of downloads / installs since that takes place via dockerhub. (Is there a way dockerhub has this data that we can get from the api?) We probably could get page hits / visits per plugin page on the website? If we added a ChRIS site management feature to the ChRIS store, we might be able to list the number of ChRIS sites that have the plugin installed. But that's definitely not a v1 feature.
Staleness alerts for the plugins - one potential issue with the plugins listed in ChRIS is there is a possibility they might be out of date with the latest upstream version of the plugin. If we can automate their being in sync, that would be awesome. Developers will likely know what the latest version of their plugin is, so if we make sure per plugin that the version number in the ChRIS store is visible, that could be a signal for them to update if they intuitively know that version number is old. Another clue we could provide them is how long ago the plugin was last updated. If the plugin (the code itself, not the metadata) was last updated a year ago and you know the latest version ois 3 months old, it's a clue that you need to manually intervene to get the latest version in the store. If there is any way to say link the plugin listing on the ChRIS store with its upstream (maybe in github) and then flag the plugin on the developer dashboard if we could somehow tell our version is older than the upstream version, that might be a good way to flag to the developer that they need to update as well.
Documentation on how to create a plugin - @jdtzmn put together some nice docs for this on the front page of the developer site, we should link to those instructions on the developer dashboard.
Button to add a new plugin - should take them to a form to fill out the metadata / dockerhub url / etc required to list a new plugin.
We need a nice landing page for when developers log into the ChRIS store. Most developers will only have one or two plugins; my guess is that it will be fairly rare for anyone to have say more than 12-20. So you can design based on a scale of most users having 1-2 plugins.
Also note the team infrastructure of apps that we'll be adding in, in the future. Assume that this infrastructure is in place, for the mockups! Ideally each plugin will be managed by a team, and each team will have at least two admins. This is because you don't want the plugin to only be modifiable by a single person who might not be available at any given time.
OK, here's some ideas for what should be on the dashboard: