Bintray comments, ratings and download count design thoughts

Projects Add-On Index
,
1

We are slowly going to start working on implementing Bintray related features for Add Ons now that @raff has completed Bintray migration of OpenMRS modules .

The first feature that we will need your opinion for is the Implementation of comments feature from Bintray.

Currently, our plan is to keep Addons as simple as possible thereby reducing the effort that will be needed to maintain it. Keeping that in mind, @darius proposed that we fetch the comments from Bintray and display it in Add Ons rather and have a button(“Write a Review”) which when clicked will redirect the user to Bintray where he can login and post the comment. This comment will then be fetched within addons.

Why do we plan to do it this way?

That’s because by doing this, we will not have to implement our own login system which will reduce the complexity of this project to a great extent while at the same time we can ensure that we don’t lose out on this feature.

Here is a mock-up of the same:

The next feature that was the Implementation of download counts.

We have a wide variety of options when it comes to this feature. We can fetch the download counts and graph it out (again a wide set of option on which library to use and also which type of graph to use) or we can just display the total download count. Please provide you thoughts on which one you would like to see in Add Ons by replying to this post . I have created one mock-up for this as well . The graph in the mock-up is actually the graph found on Bintray when we open a Module’s page

Thanks again to @raff and all who worked on the Bintray migration.

For any further questions, please contact @darius , @mseaton or me :slight_smile:

2

@reubenv i would like to first of all thank you for the great work you are doing in regards to this critical tool of our community! :slight_smile:

Concerning download counts, are you starting them afresh or will you preserve those from modulus and just add to them?

3

@reubenv this will be cool! And it’s great that we’ll get to take advantage of the move to bintray. But we should also keep in mind that people may choose to store their modules in other places too, so we should make sure the underlying design stays a bit independent of Bintray.

I took a quick peek at some different places that list addons to download:

My takeaway is that the most useful thing to show is usage of the addon. In our case we can get this from download counts (or even better, we could try to get this from usage data reported to atlas.openmrs.org). Second most important would be a rating, and last would be the specific comments. (At least, that’s generally how others have chosen to do this.)

So, I suggest that you work on things in this order (i.e. “User reviews” should be the last of the three things you implement) and that you give more visual prominence to whatever measures we can come up with of usage.

Other notes:

  1. I still stand (strongly) behind my comment that the Add On Index is just an index, and not the primary store of any of this info. So, people can comment, rate, etc, as supported by bintray, modulus, github releases, etc, and we just index this as best we can.

  2. I vaguely recall from looking at the bintray API that we don’t have access to complete historic download counts, but only to those going back a month. We could actually record this data once a month, so we could construct the complete history, but I’m not sure it’s worth the trouble. E.g. npm only shows you downloads in the last day/week/month, and as a user I’ve never felt like I needed to know more than that.

  3. I don’t see any value in showing downloads on a chart by day. This may be interesting for the author (and they can just get this from bintray) but it’s not helpful to someone who’s trying to decide whether to install the XForms module to see more than just a single summary number of downloads.

4

Here How you all are doing the downloads count?

If you increase the count using only download buttons in the Add-Ons site, that may cause some issues. For Example, I am going to collect the module information from OpenMRS Add-Ons site APIs and then will use that download link (https://modules.openmrs.org/modulus/api/releases/1169/download/dataexchange-1.3.1.omod) to automatically download the module.

In this case, How will you increase the count of the downloads? Here want to think about this API triggers also :slight_smile:

5

@suthagar23 Initially our plan was to get the download counts from Bintray.

In that case , a) There’s nothing much we can do about the increase of donwload counts due to the API. The reason being that the button indirectly links to Bintray(remember that add-ons is just an index) so each time you donwload a module, you’re indirectly downloading it from Bintray. Hence, the download count is bound to go up as Bintray will not be able to distinguish between an API download and a user download. b) Secondly, the API calls I assume, will be a rare thing right? In that case it doesn’t really matter .

Now, suppose we really want to get some credible info , in that case download counts wouldn’t be the way to go. As Darius pointed out, we could use the usage report from Atlas for this(I still have to look into as to how to go about this).

6

Actually, there may use some modules/OWA(like SysAdmin OWA) which can invoke those APIs to download and install the modules. Users will not directly come to the Add-Ons site to download those modules if they use those type OWAs.

Anyway, If the binary increases due to the API invokes, then It’s fine :slight_smile:

7

About this


My plan is that in the first release it’s fine if we do not have the total historic downloads, but just “downloads in the last month”, or basically whatever it is that bintray will give us out of the box.

However since we’ll be retiring modulus, we need to make sure that we preserve the data on module download counts in case we do want to add this back in the future.

@raff, does your plan for decommissioning modulus include saving its database?

8

I’ve actually tried to move all data from Modulus to Bintray (I hope I didn’t miss anything). The counts are saved as package metadata, see e.g. https://bintray.com/openmrs/omod/adminui/1.2.2 in the “About this version” section (it’s not displayed nicely, it should say ‘Downloads (modulus)’).

I’ll archive the database of Modulus in addition to that.

1 Like
9

This is great, thanks! I’m glad you had already thought about this.

1 Like
10

For implementing the download counts feature, I hope to go about it this way: a) Create a schedule b) Make it fetch the download counts for each version c) Include this property within this file.

@darius What are your thoughts regarding this approach?

As far as comments and ratings are concerned, I was unable to find any rest API which would get this done for us.

@raff, are you aware of any such Bintray API which fetches us the comments and ratings for each module? Another thing that I wished to get clarified is as to whether the download counts is just meta data i.e. will it take into account the current downloads as well or does it just show the number of downloads at the time of migration? From what I checked, I guess it’s static because the number of downloads as per modulus is different from that reported by bintray.

11

Yes, this sounds good. I would adding a “downloadsInLast30Days” field to AddOnVersion.

Getting a package (which I guess corresponds to AddOn, not version) has ratings: Service End for Bintray, JCenter, GoCenter, and ChartCenter | JFrog

I also cannot find comments in the REST API (where they should be called “reviews”). Further, the fact that their official Java client doesn’t support reviews makes me think it’s not supported via REST. I suggest that you add a review/comment to some module, and then try out various REST calls against that package and see if it’s stored somewhere non-obvious. E.g. maybe it’s stored as an attribute?

That said I would not spend too long searching for this. The ratings are probably more valuable than the reviews


12

Actually, maybe better to structure the way we store the download counts like this:

{
    downloadCounts: {
        last30d: 120,
        cumulative: 750
    }
}
13

@darius How should we go about this?

14

Ideally we would be able to show cumulative download counts for all time. To do this we’d need to take the total downloads from Modulus and add them to the total downloads from Bintray.

However Bintray won’t give us cumulative downloads, only the count in the last 30 days (or something like that). Therefore we won’t do the ideal thing I mentioned above. Instead we’ll do the simplest thing, and show whatever it is that Bintray gives us.

(Arguably downloads in the last 30 days may be more valuable as a metric to someone deciding what’s popular, versus cumulative total. For example the infopath formentry module which was downloaded thousands of times years ago, but isn’t used anymore.)

15

Makes sense, we’ll start with what you have said and if needed we’ll go the extra mile and add the modulus download counts as well :slight_smile:

16

@darius @raff While trying to implement this feature, I stumbled upon an issue. We do not have a premium Bintray account and hence we cannot use the Bintray statistics API which is necessary for fetching download counts.

For ex : On trying to use this, this is the output received.

{"message":"This resource is only available for premium packages."}

How should we now go about getting the download counts?

17

@raff After discussing the above issue with Darius, I guess we need a Premium Bintray account to be able to implement the feature in the way we had planned. Could you please try and request Bintray to sponsor our premium account(since they have already sponsored our Artifactory account, they might be willing to sponsor this as well)?