During the past few months, we have been hard at work crafting what will be the new backend for managing Slicer (or Slicer-based) application and extension packages.
Later today, @Pierre-Assemat and I will meet with our UI/UX designer at Kitware to discuss the next version of the extension manager frontend.
It would be great to collect your input on what worked well and what didn’t regarding the User Interface, this will help drive the requirements for the backend and associated infrastructure.
Minimal web page (similar to what is visible in the extension manager)
I created few polls (see below), please consider voting for which pros/cons/feature-request you agree the most. Based on the comment posted, I can definitively update the polls.
What I like about the current Extension Manager:
full text search capabilities
link to the documentation
link to the source code
icon
short description
screenshots
possibility to install/download extension inside/outside of Slicer
@jcfr could you refine the titles for the individual polls?
For example, it is not clear to me what “Pros:” poll title corresponds to. Should that be “What I like about the current Extension Manager:”? Or something else?
Also, suggested additions for the polls (not sure into which category they fall):
“stars” for the extensions (to me, this was a very weird feature that no one really used, due to the Midas login it relied upon - it should either be better implemented, or dropped)
“download count” (in most cases, it is bogus, since it shows count only for the given build, so I think it should also be either refined, or removed)
+1 is about the same as download count. Anonymous star system is not really good, as people may want to change their star rating.
“download count” (in most cases, it is bogus, since it shows count only for the given build, so I think it should also be either refined, or removed)
Yes, download count of specific nightly builds don’t tell much, but you can get download count summed for a range of releases using DeveloperToolsForExtensions extension. I find extension download count to be a very important metric.
GitHub would be even better, because you can log on to Discourse (and access many other Slicer resources) with your GitHub account, but you cannot do much else with a Discourse account.
Yes, download count of specific nightly builds don’t tell much, but you can get download count summed for a range of releases
The good news is that we the new backend already has an endpoint to the get the stats. It turn a maps of stats for each revision.
Or you could get the the stats for all releases using GET /app/{app_id}/release. These include download count for both application and extension packages.
It is not easy to grade extensions on a 1-5 scale, so I am for +1 system. On the web, the user should have to log in using OAuth (Google, GitHub and perhaps a few more). But it should be possible to vote using the extension manager built into Slicer. Otherwise there is not going to be a lot of votes.
We can define what we mean by each star (1-does not work at all; 3 - somewhat useful; 5 - very useful and easy to use). I’m not sure even this would be specific enough - probably getting separate stats for functionality, robustness, ease of use, documentation, etc. would be much better. It is also not trivial what would be the effect if somebody got bad ratings.
+1 should give info about how frequently used and useful an extension is - which I think is about the same information as download count.
+1 for 5-star rating. It provides more info than “thumbs up”, and I don’t think there is a need to provide any definitions - it will be hard to find someone who did not use 5-star rating in mobile phone store apps, in Amazon, etc.
The idea to authenticate with Slicer Discourse directly was to link the slicer community specifically with the rating process.
As an end user, if I was to even provide a rating for an extension it would probably be a 1 or 5. I feel like no one will provide 2 or 4 star reviews which is behavior you can usually observe on app stores or amazon pages. I would want to know with a description why someone gave a 2 versus a 1 if that was an option. Also, I would need explicit descriptions like Andras mentioned so that I could match what developers interpret a 3-star review to mean otherwise it’s a little hand wavy.
True, ratings are hand-wavy by definition. I think you’re going to have people rate only if they have a strong opinion hence 1 and 5 star ratings probably being the most popular. There would probably be more response by the casual users if the rating system was within the module somewhere instead of having to go back to the extension manager, search for the extension, and then provide the rating. As an end-user, I’d rather have a more curated experience with a most popular/featured section to guide me into picking which extensions to download instead of looking at the ratings.
I know many casual users are completely unaware of the extension manager. Those that do find it might provide 1-stars simply because the extensions usually have very few helpful screenshots and most importantly there’s very rarely any type of documentation associated with how to use the features offered in the extension (this plagues some core modules too). If I don’t know how to use an extension, I’m likely going to give it a 1-star. I know documentation is boring to write, but it really impacts if I’m going to continue to use the module/extension or just give up.
Would a 1-star rating(or down vote) due to a user-found bug or lack of functionality be cleared when the developer updates the extension? Would there be enough ratings to support clearing an extension’s rating every time it has an update? Would there be an easy communication channel(more like discourse and less github-issue based) between a user and the developer of the extension for questions how to use the extension/bug fixes/feature requests?
