We’re beta-testing a new UI for toggling cells open and closed, and pinning and un-pinning them.
- 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.
It looks like this:
If you’d like to try it out, open your JS Developer Console on beta.observablehq.org, and type in:
localStorage.FEATURE_TOGGLE_CELLS = true
… and let us know if you love it or hate it in this thread here. We’d love to hear some feedback from outside of the office.
Love it (and here’s the obligatory 20 chars)
Yes, it very much feels like an improvement. Much more natural.
I don’t have a fully developed sense of your system just yet, but this seems like a step in the right direction to me.
Very nice, much more convenient!
Thanks a lot.
I would agree that the cell label needs to stay on-screen when the cell is expanded if at all possible.
+1 this is much better, way less jumping.
One thing I would also love is if you clicked outside the cell (on the whitespace, or elsewhere) unpinned blocks hide.
Yes yes yes. So much better than having it open above. Thank you!
Thanks for all of the feedback, folks. We’ve now just deployed the new toggle UI for everyone by default.
We’ll also consider adding:
- Sticky cell names that never fall off screen for tall cells.
- Hiding unpinned cells on editor blur.
I would generally prefer code above output, especially as a notebook reader.
For example, take a look at this notebook:
(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:
This is much better.
Here’s additional idea: you limit the size of text cells to 640px, some others to 932px.
On my 4k desktop monitor, I can resize browser window to have plenty space for 2 columns of such size:
See how much empty space there is and that’s just half of my monitor.
Make the editor of the cell be on the right side when browser window size crosses 2000px or so, like in many markdown editors.
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.
Many thanks for trying this out, and for the feedback!
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?
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.)
If you click on the caret (>) instead of the gray part of the left margin, you’ll also pin the cell.
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 (▾).
When a cell is open (and not pinned, ⌄), clicking on the left margin or hitting Escape ⎋ closes it:
But when a cell is pinned, it will remain open; clicking on the left margin of a pinned cell doesn’t close it—it just refocuses it.
You can also close a pinned cell that’s not focused by clicking on its caret:
The play button (▷) is in the bottom-right of the editor. Clicking it or hitting Shift-Return ⇧↩︎ commits any changes to the code and reruns the cell.
The play button also indicates the “dirty” state of the cell; it turns blue (︎) when you have uncommitted changes.
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!