We’re beta-testing a new UI for toggling cells open and closed, and pinning and un-pinning them.
The change:
Reverses the current internal ordering of a cell, so that now the cell’s display lies above the cell’s definition. This should make things feel less jumpy as you toggle a single cell open and closed.
Adds a toggle caret, which also replaces the current asterisk for anonymous cells.
I would generally prefer code above output, especially as a notebook reader.
For example, take a look at this notebook: https://beta.observablehq.com/@mbostock/measuring-color-difference
(and especially imagine if the LaTeX labels weren’t there; such interstitial formulas won’t make sense in the middle of many types of code, and even when they are appropriate can be annoying to add everywhere in preference to the code that says exactly the same thing with slightly different syntax.)
Now the whole second half is basically out of order. Instead of cause → effect, cause → effect, etc., now we just get decontextualized numbers followed by their explanation over and over.
Wednesday evening update: I’m afraid we were a little overeager on the trigger finger with that deploy.
This toggle UI needs a bit more time and testing before we decide to roll it out in general. For now, we’ve reverted to this morning’s behavior. But your localStorage.FEATURE_TOGGLE_CELLS setting will also continue to work as before if you’d like to keep using it.
If, for whatever reason, you’d like to remove the feature flag, you can just:
Alright folks. After another few rounds of tweaking and redesign, we’ve just launched a modified version of this UI for everyone on Observable.
The cell borders have been cleaned up, the toggle caret and pinned indication combined into a single button, and the entire left margin of a cell is now a clickable toggle open/shut area.
The large unified click target is great (though I would still prefer code on top; YMMV). Can I suggest double-click anywhere in the clickable target to unpin and close a pinned cell?
visually we now have three “little arrows”: “edit/pin”, “open an object”, and “run the cell”. It’s cognitively taxing, and difficult to convey when speaking — teaching, or helping someone on the phone.
two of these icons have tooltips, one hasn’t.
having the same icon do both “open to edit” and “pin” is disturbing, because if you clicked that button you can’t just “click again to go back to the previous state” (this pins or unpins the cell), but you need to “esc” or otherwise leave edit mode. By then you have already inadvertently pinned the cell.
I love the new style of it though I prefer having my code on top, feels more natural to me. Maybe there could be a toggle option to switch between two layouts ?
Here’s a visual guide to the states and tooltips. A cell can be in one of three states: closed (>), open (⌄), and pinned (▾). The pinned state is “sticky open”: the cell remains open even if the cell loses focus. Pinning is typically used to show readers code when publishing, but it can also be useful if you are frequently editing a cell and want it to remain open.
You can click anywhere in the left margin to open and focus a cell. (You can also use Alt-Shift-Down or Option-Tab ⌥⇥ on mac OS to navigate focus with the keyboard.)
When the cell is open, the caret rotates down (⌄), a left border appears connecting the cell’s output and its source code, and the cell’s left margin turns gray. You can click the caret or hit Ctrl-Shift-P ⌃⇧P to toggle between open (⌄) and pinned (▾).
I respectfully think this particular feature feels counterintuitive and disorienting. I found this thread because I thought there was a bug in my first notebook, especially after watching tutorials where the output came after the input.
A lifetime of using command lines and REPLs and other notebooks has trained almost everyone to expect to see results display below the statement being evaluated. I didn’t realize how ingrained this pattern was until now. My fear is that breaking this convention feels too unnatural and will make it hard to collaborate with people used to IPython, etc. in the future.
Readers are always going to read from top to bottom. From a teaching standpoint, there are many examples of why you wouldn’t want to reveal the output of a function or equation before you read the equation. Now, we have to copy the equation into markdown, sort of ruining the point of notebooks and computational essays.
I think Observable is fabulous, but I’l love to at least be able to toggle this option because it’s not ideal for all circumstances. Thank you!
I want to second this. I’d love to use Observable for teaching programming, but having the result of a computation before the computation itself seems absolutely counterintuitive to me. Please consider letting users toggle the presentation order in a notebook.
And of course, thank you for an absolutely amazing tool!
︎) when you have uncommitted changes.