Public project dashboard

[CKrawczyk]

This branch is dependent on the configuration of the stats server in this PR: zooniverse/panoptes-javascript-client#29

This adds a public stats page for all PFE projects (will close #2326). It provides stats for each workflow and the number of classifications/talk posts per hour, day, week, or month.

Things left to do:

• Add URL prams to indicate the range being viewed on the bar graphs (that way people can link to a particular time range)
• Add a link to the stats page someplace on the project page (located with the counters on the landing page).
• Add and ETA based on current classification rate (or maybe add code to model a "GMB"s exponential falloff)
• Allow bar charts to be filtered by workflow

Note 1: the stats server only collects data for the projects on production, to access this page make sure ?env=production is in the URL. E.g. http://localhost:3735/projects/zooniverse/pulsar-hunters/stats/?env=production

Note 2: the gap in the classification data from Jan 13 to Feb 7 was due to an error in the stats server, not an issue on the main site.

Note 3: navigating the bar graphs for long running projects when viewed by hour is not the smoothest thing in the world, but I think it is good enough for now.

[mention-bot]

By analyzing the blame information on this pull request, we identified @brian-c, @parrish and @srallen to be potential reviewers

[mschwamb]

If this is going to add a stats link to the top navigation bar can the padding be reduced between the elements to fit more on in one line. If you've got two external links even with short titles for most reasonable sizes of the browser on my 13inch screen for both of my live projects the navigation bar it barely fits on one line. If I add any more characters to planet four: Terrains site guide link beyond 'Guide' it pushes the blog link to a second row and looks awkward.

[CKrawczyk]

@mschwamb the more I think about it the less I like the idea of putting the link in the top bar. It might be more at home on the project's landing page near the current counters.

[mschwamb]

@CKrawczyk FWIW I really like that idea

[marten]

@CKrawczyk me too

[eatyourgreens]

Panoptes client version should be 2.2 to pick up the stats server config.

[brian-c]

Why is the stats server defined in panoptes-client if it's not used there? Should an interface with the stats server interface be part of panoptes-client?

[CKrawczyk]

Ah, forgot to change that back. Thanks @eatyourgreens

[eatyourgreens]

@CKrawczyk @brian-c My first pass at a really simple stats client:
https://github.com/zooniverse/panoptes-javascript-client/blob/stats-client/lib/stats-client.js

I've tested it locally by replacing the statCount method with something like

statsClient
      .update
        projectId: @props.projectId
        workflowId: @props.workflowId
      .statCount period, type

[eatyourgreens]

@CKrawczyk here's a PR that removes the Promise Renderers and pulls the stats counts in from the API client. CKrawczyk#2

[CKrawczyk]

@eatyourgreens I just added in your changes and hooked it up so the dropdown menus fetch the new stats when changed.

[CKrawczyk]

The api calls have been updated to reflect the code changes in zooniverse/panoptes-javascript-client#39.

[eatyourgreens]

Great. I think all that's left now is to update package.json when the new version of the API client is published.

[eatyourgreens]

Small style change in zooniverse/panoptes-javascript-client@9973917 The API params should be projectID and workflowID.

[brian-c]

panoptes-client 2.3.0 has been published with the stats client.

[CKrawczyk]

OK, changes made. I also pushed latest changes to preview and everything seems to be in order.

[eatyourgreens]

This can go now that we've moved the API call to the Panoptes client.

[eatyourgreens]

Excellent. If you can remove json-api-client from package.json, I think this is ready to go.

[CKrawczyk]

Do you think I should add a footnote in about the gaps in the stats data explaining that they were caused by a bug in our event stream and not issues with the main site? I get the feeling if this is not included users might mistakenly think classifications were lost.

Since the gaps are during known times I can make sure the footnote only shows up if the project was launched before either of the gaps started.

[CKrawczyk]

@eatyourgreens I added in the following footnotes to inform users about the gaps in the stats data (they only show up if the project launched before these gaps happened):

†The gap in the classification data from Jan-13-2016 to Feb-07-2016 was caused a bug in our event notification system. No classifications were lost in this time.

‡The gap in the talk data from Feb-18-2016 to Apr-07-2016 was caused a bug in our event notification system. No talk comments were lost in this time.

Do these look reasonable?

@brian-c I noticed you reverted the version bump of the panoptes client, since this branch is dependent on that version should we hold off merging this until the issues is resolved?

[brian-c]

Yes, please wait, should be fixed again today.

[eatyourgreens]

Looks like this is good to go now.