Publishing

Options for publishing content from Jupyter notebooks as interactive web pages

Notebooks are great for exploring and developing analysis techniques, and JupyterHub's collaborative sharing of runnable notebooks is great for collaborating between researchers and teams. However, researchers also often want to share what they find in a simpler form, such as a web page, either for less-technical colleagues, for making reports or presentations, or for sharing with the public.

Expected use cases:

1. Extracting individual visualizations for use in presentations
2. Sharing sets of analyses and visualizations with less-technical colleagues
3. Publishing online demos and interactive websites

Requirements:

1. Exported notebooks should hide code cells (to simplify the page, and avoid confusing people who don't know Python)
2. Prevent arbitrary code execution (for untrusted users)
3. Allow flexible layout into a dashboard

Static approaches

First, a basic distinction: static content vs. live server. Static content does not require a running Python process, with all data stored in standard formats like PNG or HTML and at most using JavaScript in the web browser, not any Python, for viewing. Static approaches automatically meet requirement 2, as they can only support what an ordinary web page could do. Options:

A. Exporting individual notebook cells: HoloViews already supports static export of any object in a Jupyter output cell, either as PNG or as HTML with widgets, and these can manually be embedded into a presentation or web page. See the Exporting tutorial for details.

B. Exporting entire notebooks: Holoviews also already supports generating a static HTML page, embedding all of the notebook's content but customizing the look and feel. For example, see any of the IOAM documentation pages, such as http://ioam.github.io/imagen/ and http://holoviews.org. Those pages are built directly from an executed notebook using Sphinx, giving a static view of the notebooks' contents. Even though they are static, they include animations and widgets that select from pre-rendered images. Those pages show the code cells, but it's easy to hide them if desired, in such a static copy.

C. Building from a template: We could try working out a good workflow for combining option A. with an HTML templating package like jinja2 -- separately make a template for a web page with content arranged as you like, leaving hooks where auto-exported HoloViews output will be used. This approach would allow full control over the output, but seems fiddly and would require a good bit of work for every new layout, which doesn't seem very much in the spirit of HoloViews.

Of course, for any of the static options, and certainly option B, only relatively small datasets are feasible, because all of the data is hex-encoded and sent to the browser when the page loads, not dynamically, which will quickly generate impractically large HTML files. Option B also defaults to a linear (top to bottom) organization, and it is difficult to arrange things into layouts like dashboards. It might be practical to separate the images from the main page in this approach, but it will still require pre-rendering all content that can be viewed.

Dynamic approaches

A. Passing notebooks: Any .ipynb file can be passed around, and edited or run by anyone. As long as you're in a shared environment with the same installed versions and referring to external (not local copies) of datasets, it should work. You can also tag the .ipynb file with the conda environment in which the notebook was run, for replicating across different environments.

B. JupyterHub: If it's ok to allow arbitrary Python code execution (in a somewhat controlled environment), then we can use our JupyterHub server. I'm not sure if there's a way to hide the code cells, but that might be possible. But the toolbars, etc. will be visible, and this option is probably not appropriate for wider distribution beyond collaborating researchers.

C. Jupyter Dynamic Dashboards: Stores metadata in a notebook that specifies how output cells should be arranged on the page, hiding code cells (entirely), and providing a polished dashboard interface. Uses a server separate from the Jupyter server, but supporting the same API, which lets it use the same notebooks while restricting access and permissions. Highly secure versions are still in the works; not sure about how far in the future.

We'll need to show ways of selecting the data using widgets, improving the ipywidget support.