Relationship With Jupyter Notebook V7

[psychemedia]

The Jupyter Enhancement Proposal regarding Notebook V7 (JEP) refers to the document centric view of the classic Jupyter notebook UI.

In certain contexts, authors may be using the notebook UI not as an "end user" environment, but as an authoring environment for Jupyter Book content.

The visual appearance of content on Jupyter Book is much richer in Jupyter Book than in any of the Jupyter UIs (classic notebook, RetroLab, JupyterLab), for example in the provision of admonition blocks and hidden elements. Some of the "rich UI" features of Jupyter Book content may have a complement in the Jupyter UIs natively (eg collapsed content under collapsed heading) or via extensions (eg tagstyler bootstrap styled cells).

The JEP refers to offering a consistent user experience across Jupyter properties in the official jupyter and jupyterlab Github organisations, including JupyterLab Desktop, but this reflects a code-user-centric audience rather than an authoring centric audience.

Applications such as Curvenote, and publishing frameworks such as Jupyter Book) sit outside (though contribute to) the official Jupyter organisations, but do have a more author centric bias.

End-user developed extensions to customise the authoring experience and content previewing experience were relatively straightforward to develop in the original Jupyter (IPython) notebook, but are difficult (even for seasoned developers) to quickly put together using the frameworks that are likley to underpin Notebook v7.

As an author-user of notebooks, increasingly looking for ways to author content that can primarily be consumed via Jupyter Book as either:

• a static HTML or PDF book,
• an interactive book with interactivity provided by embedded HTML widgets generated as if by magic from simple code),
• an interactive book with dynamic code execution via Thebe against (in order of preference, an in-browser JupyterLite kernel, a local Jupyter server, a BinderHub server),
• an interactive notebook

One thing I am looking for is parity of experience in the visual rendering across those end-user environments as well as my authoring environment. However, the unextended notebook UI puts function over form (other than by extension), prioritising developers over authors, and this seems likely to continue in Notebook 7 / JupyterLab etc. (This is to be expected in a couple of senses: Jupyter is intended as a code creation and execution environment, so supporting code development is natural; developers develop to their own needs, preferences and biases.) For an author (non-developer) user base, lobbying developers in developer contexts can be difficult, even when just trying to articulate issues and concerns and clarify how the user experience may be falling short (at least as far as an author of interactive technical content is concerned).

At the moment, the way forward appears to be:

• author in functional/utilitarian environment; preview content for full visual effect in eg Jupyter Book; accept that the live notebook interactive experience will look nothing like the rendered content); or
• rely on the third parties to produce extensions to enhance and customise the visual appearance of documents in Jupyter UIs; or
• move to other authoring environments / workflows (curvenote, quarto, VS Code)

So I wonder: am I in a minority of one on this (quite possibly!) or do we need to find ways of promoting development of rich previews / styling in the document centric editing environments (notebook 7, RetroLab)? Or just go to other authoring environments?

[choldgraf]

hey @psychemedia - it's a bit unclear to me what exactly you're asking. Are you asking whether Notebook V7 will have jupyter book-like features? If so, I think that would be awesome and in-scope for the projects. There has already been some work getting MyST to work within javascript (https://github.com/executablebooks/markdown-it-docutils) which is the precursor to getting it to work in JupyterLab (and VSCode etc). I think it'd be really great to see Notebook v7 extensions that were designed with authoring in mind - my understanding of JupyterLab is not that it is meant for developers per-se, but that it is relatively unopinionated and relies on extensions to add more opinionated workflows, so more authoring-centric extensions would be a very welcome addition to that ecosystem IMO

[psychemedia]

@choldgraf Ooh, https://github.com/executablebooks/markdown-it-docutils is new to me... will try to have a proper look at that in next few days...

[psychemedia]

@choldgraf I was just floating a half-baked idea as much as anything, riffing on the recognition (in the JEP PR) of the "document-centric" notion of the notebook, and running with that idea a bit more: if RetroLab/notebook UI is contrasted with JupyterLab being a document-centric rather than data-sci-IDE(?) style UI, then what does that mean?

One thing it might mean is that is intended for use in creating / editing / publishing narrative style documents. And if that is the case, what are the possible output formats / natural environments for such documents and outputs that can be generated from them (Jupyter Book is one possible example). And if things like Jupyter Book are a natural target for document centric style UIs, then how can such book outputs best be previewed, other than by creating the book. And one answer to that is by having rich WYSIWYG style views in the editor UI.

But to get rich previews in the document centric UI, it's not obvious who will lead that effort. The complexity of creating extensions is beyond document authors; the effort in the core community is focussed on JupyterLab. If the community does not have a response to a rich authoring environment for document centric publications, authors will go elsewhere.

One possibility is folk will migrate to UIs like Curvenote. A second possibility is they will move to IDEs like VS Code, which has a growing number of extensions that support previews and Github (file persistence) integration (I note VS Code does not (yet? will ever?) support cell styling; nor even official support for cell editing cell tags, let alone using them to modify presentation). A third option is an editor but to support reproducible workflows, such as Quarto (which I think has WYSIWYG markdown views, but not styling at the "chunk" level.