An alternative browser/visualization based on D3

[jamesscottbrown]

I've created an alternative view of this data: https://jamesscottbrown.github.io/ai-progress-vis/index.html

Data is loaded directly from the JSON file and presented in two panels. The left displays a tree of problems/sub-problems and metrics. Clicking on a the name of a metric displays the corresponding measurements in the right panel as a coupled table and scatter-plot.

[void-elf]

@jamesscottbrown This layout is beautiful, thank you so much! Our launch was a bit rushed and we're still experimenting with alternative layouts, and we may come back to this. Is it OK if we (maybe) use your layout in the future?

[void-elf]

@jamesscottbrown Actually, would you mind submitting a PR? We'd prefer to use your design, as it's a significant improvement over our original one.

[pde]

In a Python code cell, you can do

from IPython.display import HTML
HTML(raw_html_string)

to add arbitrary HTML in the page.

You can also put CSS in a custom.css file, and the nbconvert'd notebook will load it.

[pde]

Hmmm, looking at this a bit more closely, i realised that it is not only a an upgrade to the taxonomy renderer but also uses D3 to display the graphs differently.

I think we definitely want to use the nicer taxonomy; I think we would possibly also want to move to D3 graphs (because they'll allow things like rollover data that may be impossible until Matplotlib 2.1 is released) and maybe tables, but there are a few things we should think about:

1. Can we do better than export to JSON + visualization code in JS? That seems rather hacky. Would be much nicer to make this replace the current Metric.graph method.
2. Should we consider using something like https://github.com/mikedewar/d3py ?
3. We should make sure the D3 graphs replicate all the features from the matplotlib graphs before switching over.

@jamesscottbrown let us know if you're interested in working with us to land some of this!

[jamesscottbrown]

Ok. I'll work on a pull request to generate the nicer taxonomy as an HTML list within the notebook, directly from the python objects.

Can we do better than export to JSON + visualization code in JS? That seems rather hacky

It depends where you want the visualizations to live. My thoughts on this are essentially:

The notebook interface is great for inputting data, or doing interactive data analysis. Exporting from python objects to JSON to visualize using javascript within the notebook does seem hacky.

However, for people who want to view the data, rather than edit it, the notebook interface doesn't seem to offer many advantages. It would be better to have a separate page that just provides interactive visualizations, without any constraints being imposed by the notebook format. For such a page, loading exported JSON doesn't seem hacky at all - I think it is the best approach.

My original intention was to be a first step towards a freestanding viewer, rather than something to be embedded in the notebook.

We should make sure the D3 graphs replicate all the features from the matplotlib graphs before switching over.

My viewer doesn't currently show the performance-frontier line or error-bars for uncertain publication dates; I'll add them.

[pde]

It's funny, we've been concluding that although the Jupyter Notebook is nice for entering data and crafting graphs interactively, the need to run it locally and use it with git creates fairly high barriers to entry for casual data contributions. So over in issue #37 and the editable-data branch we've been playing with moving the data into free-standing python source files, which lets us put nicely rendered HTML tables of results in the Notebook with a little link that says click here to add to or edit this data in the corner.

So I guess what that means is that we were moving towards removing the source data from the Notebook, and you're advocating removing the graphing code from the Notebook :). I think that would leave us with some Markdown notes and a few high-level marshalling calls to Python and Javascript machinery. I guess that's fine?

Anyway, I think we're conceptually okay with moving the graphs (not necessarily the tables) into JavaScript + D3. We tried a basic test of it in this branch. The need to use JSON to marshall everything is quite bad but possibly worth it for fancy interactive graphs.

We still need to evaluate https://github.com/mikedewar/d3py

[pde]

Playing with d3py a little bit, I can get it to work much like this: https://bigsnarf.wordpress.com/2012/12/30/mikes-awesome-d3-js-python-library-in-ipython-notebook/

Which is not beautiful. An iframe containing a graph is much worse than having it in the main DOM. But perhaps it wouldn't be a huge change to patch d3py to do this better.