Branching Paths: reflecting the generally non-linear flow of exploratory analysis and testing
Hierarchical Modularity: Allow collapsing and grouping of cells for organisation. Indeed, whole notebooks can be included as one unit of computation in another notebook using this framework.
Modularity II: Allow naming and documenting to be explicitly linked to code cells. Allow decoration of code cells for easy recognition while they are collapsed.
Horizontal (left to right * ) progression model: Take advantage of modern widescreen hardware, and the natural reading pattern to specify workflows that flow across the screen, with branches being represented by vertical splits. * or right to left depending on locale
Explicit linking of figure to code diff In a given session, it should always be possible to view the answer to the question: what were the code changes between Figure (state) A and Figure (state) B? Importantly Figures (states) A and B can be any Figure (or explicitly saved state) generated during the session.
Process and Design Principles
- Ease of sharing
- First-Class support for Offline / Limited Connectivity scenarios
- Always aiming to reflect mental model that people already have.
- Finding current pain points in notebook use.
- Get user feedback early (from now) and often.
How to fork / branch?
Simplest implementation is to run from start until the branch point then update cells on the new branch after the branch point only when selected.
- Communication between branches: No they should be independent
- Threads vs. Seperate instances: Seperate instances for backend to start. In browser should be sandboxed as well.
- Copy memory vs Run from start: Run from start for now. Copy could be implemented later on as an optimization.
- Where is the logic implemented: Front-end? Will work for iodide and jupyter. Back-end? Easier and maybe more powerful, + will need some backend logic for jupyter either way.