I am experiencing an issue with hiding JavaScript/TypeScript code cells in my Observable notebook.
I selected “Hide code” for several cells containing const declarations. However, the code remains visible in the public notebook, even when I open it in an InPrivate window while signed out.I have also noticed difficulties when placing multiple const declarations within the same cell.
Could you please let me know whether this is a known issue or if I need to configure the cells differently?
Thank you for your support.
Kind regards
Michael
The Observable team will no doubt respond, but the inability to hide/collapse code is certainly a known issue (from my PoV as an educator probably the most critical outstanding one with 2.0).
The new release is exciting, but I don’t envy the Observable team having to deal with many demands from us about what to prioritise.
Yep, we plan on changing this behavior so that you can hide cells more easily.
It’s not as trivial as it sounds because when editing a notebook, every cell must have some visible interface in order to let you select the cell for editing. In Old Observable, every cell was required to have an output value (even if undefined), so there was always something to display; in New Observable, cells can have zero, one, or many outputs, and similarly can display nothing or many things.
Knowing that, you can currently hide the code in New Observable by making them Unpinned and then displaying an empty placeholder, like so:
const foo = 1;
const bar = 2;
display(html`<i>empty</i>`);
The related Hidden toggle on cells is a little confusing currently in that it hides the implicit display of a cell, as when a cell is an expression (rather than a program with multiple statements, as above), or a non-JavaScript cell (Markdown, HTML, SQL, etc.). But hiding the implicit display causes the code to then appear instead (because when editing, every cell must show something)… We’ll probably change this to show <hidden> or something when editing in the future.
New Observable now has a read-only mode that non-authors see by default. In this mode, we’ll be able to hide cells completely, which should mean that an unpinned cell that doesn’t display anything (and similarly a hidden cell), will become completely invisible. You can then click the pencil to enter “tinker” mode, or fork the notebook, and see the hidden cells again when editing.
I just typed out my thoughts on the state of affairs: all the possible current states and where they deviate from naïve expectations. I didn’t even realize we had the distinction between implicit and explicit output myself.
https://observablehq.com/@tophtucker/thoughts-on-pinned-and-hidden
I’m not sure it’s entirely correct or comprehensive!
I just pushed some changes that hopefully improve the behavior.
Now when a cell doesn’t display anything, and the cell isn’t pinned (or focused), we show a small gray <empty> instead of showing the cell’s source code.
My plan had been to hide such cells completely in read-only mode (as when viewing a notebook where you’re not an author, and you’re not in “tinker” mode). But the margin collapse behavior is tricky to get right and I need a little more time to get it working. Stay tuned!
Thanks so much for the work in this issue.
It’s an interesting one because it gets to the heart of what makes a computational notebook / literate computing distinct.
For me, a computational notebook is characterised by the following:
- A formatted text authoring environment
- A code development environment
- Integration of output from code with textual output for human communication
- Provides an indication of what is computed and what is directly written by the author
- Invites exploration / adaptation of code and written content
- All the above in a single environment from the author/reader point of view
Points 1 to 3 are self-evident and pretty much define the minimal attributes of any notebook environment. They can also be reproduced with conventional separate full-stack development stages.
Point 4 is more subtle and might drive how to handle hidden/exposed code blocks. Entirely hiding the ‘computational workings’ just replicates full-stack web development leaving the notebook as a convenient working environment rather than a distinct form of communication. But fully exposing computational workings likely interferes with effective human communication. This is especially true for a reactive notebook where textual narrative and code are likely to be interleaved.
The ability to expand a cell to see its code along with a visual indication that a cell can be expanded are important here. It provides a means of ‘narrative accountability’ inviting, but not requiring, scrutiny. The left gutter and ‘grey bar on hover’ mechanism in Observable do this well and support point 5. And the pinned/unpinned mechanism is an elegant solution for allowing authors control over whether code is directly part of the narrative or just in support of the narrative.
Consequently, I am less persuaded of the value of a separate ‘hidden / unhidden’ option. As Toph’s page illustrates, the combination of pin/hidden options elides two overlapping but distinct concepts without an obvious benefit. In the spirit of streamlining the interface, I’d favour dropping the hidden option entirely, instead relying on unpinned cells for reducing code exposure. That requires the visual indicator of unpinned code cells are sufficiently explanatory/inviting while not interfering with the surrounding textual narrative.
Very thoughtful feedback, Jo. It brings me joy to have your and the community’s help solving these challenging design problems.
One of the biggest but subtle differences in new Observable is the new read-only mode that is seen by non-authors. We introduced this mode for two reasons: (1) it prevents a lot of accidental edits by readers, whether within a team where such accidental edits would be saved automatically and potentially corrupt the notebook for future readers, or in the public where it can break the notebook for the individual reader; and (2) it allows us to suppress the editor affordances and focus more on content when reading.
As you say, one of the fundamental properties of a computational notebook is that it invites exploration and adaptation, what Bret Victor called the active reader. For this reason, critically, even though the new read-only mode deprioritizes the editor affordances, we want it to be easy to exit read-only mode without losing context or runtime state.
You can therefore exit read-only mode by clicking the pencil button which is always visible in the bottom-left corner (except on mobile, and we’ll figure out a place for it there soon). You then enter edit mode (if you have permission to save changes) and otherwise “tinker” mode (where changes only exist in-memory). Forking from tinkering doesn’t yet preserve your tinkered changes, but we’ll fix that, too.
We think this is a big improvement, but it does make notebooks slightly more “opaque” by diminishing the editor in favor of content, at least if the author wants it to be (by unpinning cells). But in the pedagogical context, if you invite readers to fork or enter tinker mode, they can start in the edit mode immediately and tip the scales more towards exploration and adaptation. It’s a subtle shift but we think this gives both authors and readers more control, and certainly it makes it easier for us to design because we can now optimize the reading and editing interfaces semi-independently.
Yes, I really like the design of the read-only mode with the well placed, but not dominant, edit/tinker icon. It’s exactly the right balance between ‘perhaps you’d like to be a more active reader’ and ‘Take care! You’re in the programmer’s workshop’. It creates an interesting new space between blog and coding platform that I don’t think other ecosystems with computational notebooks (e.g. R, Python, Julia) have quite addressed (yet). It has exciting potential for archivable open science publication too.
My points about the hide / pin complexities were about how the design philosophy best works once in the active reader environment. This is where I see less value in the interface facilitating hiding cells entirely. The existence of a read-only mode where unpinned cells do disappear, means there’s even less reason for a ‘hide cell’ option.