New Notebook Cell Toggle UI (Feedback Wanted!)

Dear Observers,

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.

It looks like this:

If you’d like to try it out, open your JS Developer Console on, 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 like that it feels more stable, now that the cell’s display remains fixed when toggling the definition
  • i like that collapsing the definition now automatically unpins
  • suggestion: i wonder if showing ">" only on hover would keep the display simple as it was before
  • suggestion: sometimes the cell display is taller than the screen, maybe make the "name ▾" label stick to the top of the screen if scrolled out of view

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.

1 Like

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:

delete localStorage.FEATURE_TOGGLE_CELLS


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?

Very cool feature.

However in terms of UX:

  • 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.

1 Like

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 ?

1 Like

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 (:arrow_forward:︎) 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!