Slicer Extension Manager: User Interface Feedback

#1

Hi Slicers,

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.

Links:

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
  • when using the web version, the URL is updated

0 voters

Show results

Issues that impact my user experience:

  • not all icon are showing up
  • category are hard to read. (why Virtual Fracture is in Examples -> Virtual Fracture)
  • web version doesn’t show the latest available extension for each platform. You have to enter the revision.

0 voters

Show results

Feature I wish to have:

  • sort alphabetically
  • markdown support for description
  • share on social network
  • licenses used in the extensions are not listed. See #2171
  • list of modules bundled in the extension not available
  • list of funding grants
  • include acknowledgments. See #3415
  • list of associated publications
  • add link between download.slicer.org and the extension manager
  • add concept of channels. (possibility to select a channel for installing/downloading extensions uploaded by a user, a lab, …). See #2334
  • extension should list their dependencies. See #3696
  • google analytics

0 voters

Show results

What type of stats should we keep around ?:

  • download count (assuming it is kept around even if the extension is removed)
  • download with IP location, date, time, …
  • behavior of the user using Google analytics or pixel beacon (which page, how long, which action, …). User could opt-out.
  • anonymous “stars” rating
  • anonymous “+1”
  • identified “+1” (assuming you can login using Google Account / GitHub / …)
  • identified “stars” rating (assuming you can login using Google Account / GitHub / …)

0 voters

Show results

References:

Policies around supported browser versions for Girder platform
Maintenance of slicer.kitware.com planned on Thursday April 18th from 2 to 3pm EDT
#2

@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?

1 Like
#3

Thanks for the feedback. Let me know what you think.

1 Like
#4

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)
#5

What do you mean by “when using the web version, the URL is updated”?

#6

stars rating

“stars” for the extensions

We talked about removing that. And instead, we were thinking to have anonymous “+1” system.

download stats

These data are from our test server.

“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)

In the new backend, download count are kept around at the release level in a json document. For example, for release, it like this:

image

and for draft release (aka preview / nightly), we also keep track of it:

image

1 Like
#7

This should illustrate:

web-url-updated

1 Like
#8

Would be cool if instead the users werr authenticated against Slicer discourse.

#9

+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.

#10

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.

1 Like
#11

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.

image

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.

image

2 Likes
#12

There is officially support for Google Auth, and available implementation for few others including GitHub:

image

1 Like
#13

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.

#14

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.

2 Likes
#15

+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.

#16

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.

#17

IMHO, ratings are hand-wavy by definition …

#18

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?

#19

A post was merged into an existing topic: Trouble with Extension Manager

#20

Sounds like proxy option should be added to the list in the poll above.