edsu / wikipulse Goto Github PK

Is it due to heroku limits or...?

Hi, Ed. Could you add some Indic languages to this neat viz? Specifically, it'd be great to have the following language codes: bn, hi, ta, ml, te, kn, pa, mr, gu, or, ne, and ur.

For the last few weeks, I've always seen wikipulse giving wrong counts on http://wikipulse.herokuapp.com/ . For instance now it says 6 edits per minute when I'm watching a bot on wikidata which alone makes a few dozens edits per minute.

Wikidata has been constantly over the current single-gauge max value of 300 edits / min, often hovering around 800 or 900. This leads to totals well over the current global max value of 1000 edits/ minute.

Consequently, some adjustment of the scales would be useful, perhaps in a way that treats Wikidata differently than the other single gauges.

I've tried loading wikipulse in Internet Explorer 8 (not my fault, a public building): it loads the main meter, with a number, but doesn't update said number nor load the meters for individual wikis. Compatibility mode seems disabled, so it should not be pretending to be IE7.

The visualization could be a lot more interesting if the gauges used a logarithmic scale. Currently most of the pointers linger near zero, and a couple of more active projects hang consistently around middle-ground values, with occasional spikes that send them over the limit. Increasing the limit would create some room for these spikes, but would glue the less active projects even more to the zeroth position; decreasing the limit would make the fluctiations of the small projects more visible, at the expense making off-the-scale events unacceptably frequent for the larger projects.

A log scale would fix both issues neatly. Unfortunately, Google Charts doesn't support a log scale for the gauge chart type, but I found a web chart library, called HighCharts, that does. It's free for non-commercial use, so we should be fine using it. Here's how it would look: http://jsfiddle.net/8LB8V/. What do you say, @edsu?

It would be easier to compare different Wikipedias (and more visually interesting) if the gauges had ranges painted in colors (using the greenFrom, yellowFrom and redFrom configuration options of the gauge chart).

I'd suggest a scale like this:

• from 0 to 60 edits per minute (below 1 edit per second): green
• from 60 e.p.m. to 300 e.p.m. (between 1 and 5 edits per second): yellow
• from 300 epm to 600 epm (between 5 and 10 edits per second): red

The implementation is simple:

var options = {
    greenFrom: 0, greenTo: 60,
    yellowFrom: 60, yellowTo: 300,
    redFrom: 300, redTo: 600,
    max: 600
}

This means that the max would be 600, not 500 as it currently is. Alternatively, I'd suggest maxing out at 300, since that range covers most typical values, and allows better resolution in the low-activity projects (besides, the gauge is able to properly handle abnormally high values):

var options = {
    greenFrom: 0, greenTo: 60,     // 0 to 1 edit per second
    yellowFrom: 60, yellowTo: 180, // 1 to 3 edits per second
    redFrom: 180, redTo: 300,      // 3 to 5 edits per second
    max: 300
}

Of course, the large cumulative gauge would have to use a different scale, say 1200 max instead of 1500; so the ranges would be doubled if we use 600 as a single-project max, or quadrupled if we use 300.

If this is a change that would be welcome, I can submit a PR.

node-irc is better maintained, and works with latest versions of node...

http://wikistream.wmflabs.org/ looks dead (https://phabricator.wikimedia.org/T183826), it can be great to replace these links to Special:RecentChanges page for each wiki.