- The problem that this enhancement addresses. If possible include code or anecdotes to describe this problem to readers.
Creating conference-quality presentations with the Notebook requires a good understanding of the limitations of the notebook, nbconvert, reveal.js, RISE and the publishing platform (nbconvert and hosting, or nbviewer). The user is forced into a particular mindset about how slides are structured and authored, based on the these limitations, and at the end is still left with a potentially fragile artifact that doesn't reflect the amount of effort that goes into its creation.
Jill is presenting in support of her journal paper at a conference. While performing her work in Jupyter notebooks, she has prepared some beautiful visualizations and meaningful code snippets, as well a number of content pieces which are included in the draft and final versions of her journal paper.
She has seen some example slide decks on nbviewer that use reveal.js, and they look pretty neat, so she decides to turn on the Slides cell metadata and starts a brand new document, copy-and-pasting the content from her notebooks, making some screenshots.
Going back and forth between some command line scripts, her local web server and her notebook, she finally has something she can present. The resulting presentation looks pretty ho-hum, and has some formatting issues, but gets the point across. Right before the presentation, the organizers tell her they need a ppt or pdf of her slides, as there are A/V issues, and she won't be able to connect her laptop directly or use the internet during her talk.
She decides to just use LibreOffice next time.
John maintains a family of presentations, which are frequently updated for customer courses. While the content is light, the format represents his corporate and personal brand, and is a selling tool for his organization. In addition to wanting to create printed take-home materials, he has slides that contain interactive features.
Jack has experimented with showoff, beamer, but keeps ending up with LibreOffice. He evaluates using the notebook for his presentations, but finds that it lacks a number of key features: reuse of slides, repeatable PDF output, slide numbering, branding for his company and others.
He tries using showoff, but still finds it requires a lot of knowledge of CSS and html, and even has to learn some ruby. He decides to just use LibreOffice.
A brief (1-2 sentences) overview of the enhancement you are proposing. If possible include hypothetical code sample to describe how the solution would work to readers.
A detailed explanation covering relevant algorithms, data structures, an API spec, and any other relevant technical information
The authoring and live presenting experience should dominate nbpresent design choices. A significant shortcoming of reveal, showoff, and beamer are required knowledge of some form of esoteric language(s) to get your presentaton to Look Good. LibreOffice has mostly succeeded here with its drag-and-drop UI, but makes it more difficult to achieve a designed, consistent layout, as you are given free reign to make pixel-level corrections, sapping productivity.
Somewhere in between is a system that achieves separation of content, composition, layout and style which allows the user (and eventually a team) to concentrate on the appropriate task at hand, evolving an outline into a delivered, polished, and rehearsed presentation.
For rapid authoring, an author needs to be able to drop in and out of the logical model of the traditional notebook view, the tooled slide authoring view, and a full-on presentation view, suitable for delivering presentations which include rich widgets and require execution.
At the end of the process, a user will need to be able to hit "publish", initially to some simple choices like PDF, a standalone HTML file, or a zip of their file ready to be hosted on a plain-old-host (github/google pages). Jupyter Notebook Viewer represents a specific publishing target, and will have to be able to provide a out-of-the-box compatibility.
At a granular level, cell inputs and outputs, and to an extent, widgets, will be the content that make up presentations, but there is seldom a one-to-one mapping of cell to slide, cell to part-of-slide, or part-of-cell to part-of-slide. Furthermore, presentations frequently represent the unification of a number of sources, and need to be remixable, suggesting there is not a one-to-one mapping between notebook and presentation.
We propose allow using per-cell metadata to allow mapping each cell's input (and outputs, for code cells) to a specific region of a slide. Since cross-notebook cell transclusion must be possible, we will need to be able to assign stable identifiers to cells, and by extension their inputs and outputs.
One key aspect of presentations (as opposed the the incubating dashboards) is working within the boundaries of the presented screen... whichever screen: desktop, mobile, hi-res presentation. Pixel-based approaches to this are significantly limiting.
To work within this, a constraint-based system, built on a cassowary-derived engine such as kiwi.js is proposed.
Today, it takes heroic effort to view a notebook-as-slides in anything other than the stock default. Unlike the notebook, where consistent UI is a feature, presentations need to represent the brand of the author and/or their organization.
Intertwined with regioned layouts is CSS, fonts, images (and potentially JS, such as typographic effects) that enables a specific branding of a presentation. These theme assets need to be referenced/embedded along with presentations, with effective fallback to a default brand (such as on nbviewer).
A huge advantage of showoff and beamer is the (technically adept) user's ability to reuse content.
A presentation notebook needs to be able to bring in one or more cells (inputs and outputs) from other slides. These guest cells would not be editable within the host notebook, and refreshing of guest cells should be as painless as possible (automatic on save, if possible, on keystroke, eventually).
The most challenging part is the presentation system itself. The current choice, reveal.js, has gotten us very far, but is turning out to be challening to support: its CSS, build chain, and opinions make it a poor match for the kinds of complex HTML that come out of notebooks, as well as the design goals of many of our users.
The initial implementation would continue to use reveal, but would not try to directly translate cells to <section> content.
This feature would be packaged as a number of npm modules, using current Jupyter front-end development practices:
PhosphorJS is a strong contender for the underlying layout engine, specifically the proposed constraint-based layout, and will be generally available in the notebook in a roadmapped version.
In addition to the core rendering functions, specific components would be packaged as plugin modules that carry their own JS and CSS:
Several of these plugins would be packaged with the pip/conda-installable Jupyter package, but these could be added/upgraded by the user.
A list of pros that this implementation has over other potential implementations.
A list of cons that this implementation has.
A list of individuals who would be interested in contributing to this enhancement should it be accepted.
In [5]:
# these customize the environment
from IPython.display import Javascript, display
foo = [display(Javascript(url=url)) for url in [
"https://bollwyvl.github.io/nb-inkscapelayers/main.js",
"https://bollwyvl.github.io/nb-mermaid/init.js"
]],