jupyterlab_voyager
jupyterlab_voyager copied to clipboard
UX of opening/saving/exporting files in JupyterLab
@ellisonbg , @zzhangjii , and @tgeorgeux worked today on the UX of opening files in JupyterLab. We've identified three different input scenarios which we will summarize below:
.csv/.json/.tsv files
- Files open by right-clicking in file browser and selecting 'Open with... Voyager' in context menu.
- Don't auto create a vl.json file.
- Save/Save As are disabled.
- Export voyager as vl.json, Export voyager as vl.json with inline data. (Still working out copy for this option)
- Future (dependent on JupyterLab datastore work): Save file path of data source and spec to datastore to enable work recovery on crash or reload.
vl.json files
- Files open by right-clicking in file browser and selecting 'Open with Voyager' in context menu.
- Save/Save As are enabled.
- Export disabled.
- Future (dependent on JupyterLab datastore work): Save file path of vl.json and spec (exclude inline data block if exists {this will require further exploration when implemented}) to datastore to enable work recovery on crash or reload.
Table/Altair in a Notebook Cell
- Files open by right-clicking in table in notebook and selecting 'Open with Voyager' in context menu.
- Don't auto create a vl.json file.
- Save/Save As are disabled.
- Export voyager as vl.json with inline data. (Still working out copy for this option)
- Future (dependent on JupyterLab datastore work): Save file path of notebook with cell ID and spec (exclude inline data block if exists {this will require further exploration when implemented}) to datastore to enable work recovery on crash or reload.
- Future: explore how to export view back to notebook without losing context.
@gnestor @jasongrout Can you both take a look at this and see if this UX makes sense in light of what we spoke about this morning in the JupyterLab Developer call. Does it also make sense for the plot.ly extension?
I suppose this is assuming that the right-click in the notebook is on a mimetype that somehow exposes its data, not just a rendering of data in the kernel.
This looks like it captures some of our discussion this morning. I would say the csv/json/tsv file renderer is probably the biggest quick win, though the .vl.json viewer may make sense to do first.
If I have a DataFrame in the notebook it would be nice if there were a toolbar which would allow me to select between various different views of the data (with voyager being one of them)
This has been discussed in a few places before:
https://github.com/ipython/ipython/pull/10527#issuecomment-303536855 https://github.com/jupyterlab/jupyterlab/issues/3038#issuecomment-351443367 https://github.com/jupyter/notebook/issues/2685 https://github.com/jupyterlab/jupyterlab/issues/1194
...and IIUC has actually been implemented in nteract as the dataresource renderer: https://github.com/nteract/nteract/issues/2324
My (vague) thoughts are that libraries could register themselves with the dataresource renderer which would then add an icon to the renderer toolbar which would then display the data using the appropriate extension - e.g. BeakerX table, plotly plot, voyager data explorer, etc...
That sounds great! I would still suggest doing the file viewer approach first, to nail down the voyager widget itself with static data, and then tackling the 'generic data visualization' widget.
The assumption you made about right clicking a mimetype is correct.
Additionally, what we don't currently have is a useful way to export the Python code in any readable format due to the increased complexity of Vega Lite 2 and Altair 2. In that sense we're a bit blocked on how to export back into notebook. I could see making the visuals in voyager and then replicating them with Python code back in the notebook, but exporting readable Altair code right now is pretty dicey.
Hey @tgeorgeux just following up on this for clarification...is this a tracker to change the user experience of saving/exporting, or is this used to track the completion of the feature itself.