generating "downloads badges" for repos?

[cboettig]

Hi Gabor,

Would you consider having this app also generate svg badges for the number of downloads, in addition to the json summaries? Several of us were discussing this idea over at ropensci-archive/wishlist#14

Thanks for considering!

Carl

[gaborcsardi]

Hi Carl, great idea! It is really a pity that we only have data about one server.

Sure, I can do that. Should we use shields.io? If I understand it correctly, we would download the SVGs, and then serve them from cranlogs, with the appropriate numbers included. Right?

So what kind of badges do we want?

• x total
• x/day
• x/week
• x/month
• different colors?
• flat?
• plastic?
• flat-squared?

We probably want to abbreviate large numbers: xK or xM.

How should we calculate x/day, x/week, etc. Only (say) for the last year?

[cboettig]

@gaborcsardi good questions!

Yeah, that's the workflow I envisioned. (Though I'm not sure if it will be easiest to actually ping and download from shields.io each time vs just have the app write out an svg templated off of the one shields.io creates but with the download stat stuck in the right place)

For kind of badge, my intuition is just to go simple, e.g. total downloads. This is the kind of thing people will probably just glance at, and may compare across R packages, so it might get confusing if different users are reporting different intervals and people don't read the text carefully enough to see that one is x/week and one x/month or something. Wish I had a sense of what was most common to report.

Likewise not sure what aesthetics would be best. My intuition is to just pick something and hope you get feedback from the community one way or another.

I suppose in a fancy implementation of this, the badge could link to a little summary page with more information (e.g. day, week, month totals, go crazy and add a graph over time, and have some credits linking back here for where the stats come from).

[gaborcsardi]

Yeah, that's the workflow I envisioned. (Though I'm not sure if it will be easiest to actually ping and download from shields.io each time vs just have the app write out an svg templated off of the one shields.io creates but with the download stat stuck in the right place)

I would just use the template. It is unlikely to change anytime soon.

For kind of badge, my intuition is just to go simple, e.g. total downloads. This is the kind of thing people will probably just glance at, and may compare across R packages, so it might get confusing if different users are reporting different intervals and people don't read the text carefully enough to see that one is x/week and one x/month or something. Wish I had a sense of what was most common to report.

I guess total downloads is fine. Of course you cannot compare an old and a new package that way, but never mind.

Likewise not sure what aesthetics would be best. My intuition is to just pick something and hope you get feedback from the community one way or another.

I liked the blue ones in the linked issue, so I'll go with those. What should the label be? "rstudio mirror downloads" looks a bit too verbose.

I suppose in a fancy implementation of this, the badge could link to a little summary page with more information (e.g. day, week, month totals, go crazy and add a graph over time, and have some credits linking back here for where the stats come from).

Yeah, that's for later. :)

[cboettig]

Great, sounds like a plan! Awesome that you are doing this.

I'd just go with 'downloads' and for now just link the button back to this repo or somewhere that explains that these are total downloads but from only the R mirror, and file an issue if you have ideas/opinions about how to present this badge differently.

it's awesome that you're doing this!

[sckott]

🚀

Nodes badges https://nodei.co/ - These are obviously more complicated than we need, but present some options to think about down the road

[karthik]

For kind of badge, my intuition is just to go simple, e.g. total downloads.

I'd agree. I also think it's not a good idea to change colors. People will mentally start looking for the badge and it doesn't make sense to confuse them.

[karthik]

Of course you cannot compare an old and a new package that way, but never mind.

@gaborcsardi I was thinking the same earlier today too as I was fixing our status page. I know the relative age of packages, but a naive user wont. This metric cannot be computed on the fly, but it would be good to run weekly on the whole index. Package x is in top % of downloads compared to packages of similar age. Something like that.

[gaborcsardi]

OK, how about these?




http://cranlogs-dev.r-pkg.org/badges/git2r etc.

If it is OK, then I'll push it to the "production" server (drop the -dev).

[karthik]

amazing!

[gaborcsardi]

:)

@karthik Top x% of downloads sounds very good, but I would rather go with downloads/month for the last 12 months, so then it would be something like "Top 5% downloads this year".

OK, pushed to the production server. We can still change it of course. If it looks good, I'll add it to the README.

The difficulties are

• the fonts, what if they are not available, then font sizes might be wrong
• the size of the badge is fixed, so when we reach 100M downloads for something, I need to make the badge bigger. :)

[karthik]

the size of the badge is fixed, so when we reach 100M downloads for something, I need to make the badge bigger. :)

Sounds like a good problem to have!

Top x% of downloads sounds very good, but I would rather go with downloads/month for the last 12 months, so then it would be something like "Top 5% downloads this year".

I like this approach especially since we don't have data going back too far (Nov 2012 if I recall correctly). This metric is more useful since I'd like to see what's been popular in the last 12 months than something more cumulative.

[gaborcsardi]

I like this approach especially since we don't have data going back too far (Nov 2012 if I recall correctly). This metric is more useful since I'd like to see what's been popular in the last 12 months than something more cumulative.

OK, I can make another badge for this, in a different color (orange?), the only question is what to show if the package is not in the top 50%.

Otherwise I would have 50%, 25%, 10%, 5%, 2% 1% I guess.

[karthik]

OK, I can make another badge for this, in a different color (orange?), the only question is what to show if the package is not in the top 50%.

What about returning a SVG version of a transparent image? So nothing shows up for those folks.

Unrelated question, GitHub tends to cache images that are referenced in READMEs (just click on the badges here for e.g.). I wonder if it does check to see if there is an update before caching again? Otherwise the download count would be stuck at first load.

[gaborcsardi]

What about returning a SVG version of a transparent image? So nothing shows up for those folks

That works. I am just a little worried that we embarrass all package developers that get the transparent image.

Unrelated question, GitHub tends to cache images that are referenced in READMEs (just click on the badges here for e.g.). I wonder if it does check to see if there is an update before caching again? Otherwise the download count would be stuck at first load

Yes, it is caching it, and a reload does not hit my server. I can try to add an Expires header, to see if that helps.

[sckott]

Expires header seems right. In the travis-ci header they have

< Expires: Thu, 23 Apr 2015 13:32:06 GMT

the request was made at the same time essentially

[gaborcsardi]

@sckott @karthik OK, I added an Expires header, hope this helps.

Not sure how to invalidate the Github cache, though. :(

[gaborcsardi]

Related smaller issues: #6 #7 #8

I think these cover everything we discussed here, so I'll close this one now. You are welcome to reopen it if I missed something, or just open another one, of course.

[cboettig]

awesome work, very nice!

[karthik]

Not sure how to invalidate the Github cache, though. :(

Yeah, this isn't happening yet.

[gaborcsardi]

Yeah, this isn't happening yet.

Rstudio only provides the logs at the end of the day, so this is not real time. It will only be updated tomorrow, anyway.

Adding monthly, etc. stuff now. When it is done, then you can use a new URL, and that won't be cached. You'll see tomorrow, if it has changed, and if not, you can use the new URL.

[karthik]

Rstudio only provides the logs at the end of the day, so this is not real time. It will only be updated tomorrow, anyway.

I mean't from yesterday to today. Badge shows 73. Current badge retrieved from your site shows 93 (for rdrop2 which is a < 7 days old). That's what I mean by GitHub not invalidating the cached file.

[gaborcsardi]

You can try a URL with a dot after the hostname, this is the proper form, but nobody uses it. If the cache engine is not too smart, then it will consider it as a different URL:
http://cranlogs.r-pkg.org./badges/rdrop2

[gaborcsardi]

OK, so how about switching to per month by default? Examples:

• Default is per month: http://cranlogs.r-pkg.org/badges/pingr
• You can do per week: http://cranlogs.r-pkg.org/badges/last-week/pingr
• Per day: http://cranlogs.r-pkg.org/badges/last-day/pingr
• Or the grand total: http://cranlogs.r-pkg.org/badges/grand-total/pingr

[karthik]

Sounds fantastic! 💯

[cboettig]

🏆

[sckott]

looks bueno https://github.com/ropensci/rgbif#rgbif

[gaborcsardi]

OK, I'll push this in a sec. Done.

@scott please drop the -dev from the URL, as this is for the dev server, and that is often broken. I'll update the URLs in the comment as well.

[sckott]

@gaborcsardi okay, will do

[brendan-r]

Just a note on the caching thing - the header to set seems to be Cache-Control: no-cache.

[karthik]

@brendan-r By design, so badges don't get stuck on a the first day of install's download count.

[gaborcsardi]

@brendan-r Cool, thanks, I'll add it in a sec.

[gaborcsardi]

@brendan-r OK, added.

I hope that Expires worked, too, because I don't want to invalidate all my cached badges by hand.

[brendan-r]

Working like a charm now, thanks for all your work on this!