The UX of Notebooks 2.0 vs Framework

[jwoLondon]

I am liking the way Notebooks 2.0 is going with the file-based approach and a move to vanilla JS. I was finding myself forgetting the differences in workflow between Notebook 2.0 and Framework, which got me thinking about whether the UX should feel more different, especially via Observable Desktop.

I still regard the idea of reactive notebook-based programming as the key innovation in programming of the last decade (and Observable has been influential here), so I hope Notebook 2 builds on those strengths. For me, if I am working on a project that needs to be coding-first, I'd be using Framework in VSCode, but for literate programming (which I love), I use notebooks.

Personally, to reflect this, I'd like to see Observable Desktop feel more like a markdown editor into which JS can be inserted, rather than a JS editor into which markdown can be added. I'd love to see, for example,

• default new cells being markdown rather than than JS,
• perhaps an easier way of moving cells around in the editor (to emphasise 'narrative-first' design thinking rather than coding-first).
• For unpinned JS cells in the editor, a more minimal holding place rather than forcing the code to be displayed (this would also more strongly mimic the appearance of the deployed page)
• For code cells, having automatic Prettier-style formatting in the Desktop app would be great as it removes wasted cognitive effort, especially for beginners.

I think this would also make onboarding into the Observable ecosystem more attractive (I teach a lot of people code-based visualization for whom Observable is their first experience of coding, and the markdown/narrative entry point removes several of the barriers to entry I've seen (and created!) in other systems.

[mbostock]

Great perspective, thank you for sharing! A few thoughts…

There are many ways to insert Markdown today:

• Split the currently-focused Markdown cell with Option-Enter
• Option-click the + inserter between cells
• Insert a new Markdown cell below the focused cell with Option-Command-Enter
• Insert a new Markdown cell above the focused cell with Shift-Option-Command-Enter
• Insert a new Markdown cell below the selection-focused cell with Option-Enter
• Insert a new Markdown cell above the selection-focused cell with Shift-Option-Enter
• Hit Down in an empty JavaScript cell to switch to Markdown
• Hit Command-2 to switch the focused cell to Markdown
• Use the mode drop-down menu

(A few of these are shown in the Desktop user guide.) The first might be the most common, at least for me, since new notebooks start with a Markdown cell by default.

I’m expecting in the future that the Desktop editor will have user preferences and configurable keyboard shortcuts. When this happens, we could perhaps have a setting that lets you swap JavaScript and Markdown in some contexts. (I’m not sure yet whether this would be a single setting, or separate settings for some of the above controls.)

I don’t think we should change the default behavior. Inevitably some will not like the default — that’s why we want user preferences — but JavaScript is by far the more popular choice based on empirical usage, and based on what I’ve heard anecdotally. And I think philosophically that Observable Notebooks are “more JavaScript than Markdown” in the sense that there are a lot of alternatives for writing Markdown, but not many for writing reactive JavaScript. Perhaps promoting Markdown more would bias notebooks in a more literate direction, but I feel we’re already striking a pretty good balance here (for example by adding a Markdown cell to new notebooks).

I would love to make keyboard shortcuts and cell selection more discoverable. I feel keyboard controls are almost essential for productivity; mouse controls are easier to discover but often harder (slower) to use and hence self-limiting. Even so, I plan to implement drag-and-drop to reorder cells… and ideally this time I’ll figure out how to select multiple cells and drag them together.

There’s been some internal discussion about a “hidden” state to allow cells to hide both their code and their display. The design currently doesn’t support this because you need something to click on to refocus a cell, so one of the two must be visible. (As mentioned in #34.) I’d like this “minimal holding place” as you put it, but we haven’t designed it yet.

Desktop supports Prettier using the Shift-Command-I keyboard shortcut. (It also trims trailing whitespace automatically when you commit a cell.) Again, when we add user preferences, we could have a setting that enables Prettier automatically. But I don’t want to force Prettier on users by default.

[gganapat]

Amazing to see how this is progressing. Any chance of having data loaders as well like in Framework? This was another groundbreaking feature to work in multiple programming domains.

[mbostock]

Yes, we’re interested. I’m working on database connectors right now — we want a more convenient solution specifically for SQL databases — but we’re also thinking about how that might generalize to other languages and ways of loading (and baking) data.

[gganapat]

Looking forward to it!