View-only mode?

Hi, I’ve only been playing around with Observable for now, but am already super impressed! I’d really like to use it more in the future.

My first experiment was visualizing responses to a survey. The problem is, I don’t want to expose this data to the viewer—just the graphs. This is somewhat similar to what was discussed in this topic on backend data stores, or this discussion about exporting notebooks as bundles, but I think I’m asking for a different thing:

Can you add a “view-only” mode that shows only the rendered content of the cells? (Should probably also exclude cells that contains previews of JS objects and not DOM nodes.) I know this is against the general sentiment of having explorable data. It’s a quite easy way to let people use Observable with otherwise private data, though.

I’d be totally fine with having a button to export the content, too, without publishing it to the site.

To keep the original data private, I recommend aggregating your data in a separate private notebook (which you don’t publish; or, do the aggregation outside of Observable), and then only make the aggregate data public. Since the aggregate data contains the same information as your visualization, this approach would not expose any new information—the data and the visualization are informationally equivalent.

Oh! That’s a very neat idea, thank you! (I knew I could just aggregate the data offline, but then the feedback loop is much slower.)

This totally adds “collaborative editing” to my feature requests, though :wink:

I’ve drafted a notebook that is intended to be more like a blog post for non-programmers than a notebook for other coders. Is there a way I can publish it and hide 100% of the code so a reader will only see the output?

You can see the draft here.

Once the 2018 baseball season starts this week, I will expand the chart to include a “live” line tracking the bet with some emphasis and perhaps a projection as well. I’d like to share it with a group of friends who aren’t programmers.

There currently isn’t any way to hide the code from readers — aside from resorting to dirty tricks, like stuffing all of it into viewof cells that run code as a side effect and return a Markdown paragraph as the view.

I’d certainly be interested to hear more about the workflow that you’re looking for, with this example. Just a per-cell toggle that makes some cells invisible to everyone besides the author? Something more sophisticated?

1 Like

Thanks for your interest. I can’t say I have an easy answer, but I have admired how R Markdown has made the code less conspicuous. Here’s an example published recently by The Washington Post.

Generally, the design generated by R is inferior to what you guys have done, but I do like how the code can be hidden behind a button with the “code_folding” settting.

Obviously, you guys fold your code as well, but the fact that the outputs are printed onto the page makes it harder to ignore. One option would be to make that less conspicious, or to allow a setting that would hide the output. Another option I can think of would be an alternative URL like /html/ or /read-only/ or whatever at the end of a published page’s URI that, like Google Sheets, would offer a stripped down version of the page without any of the editing features.

1 Like

I’ve been referring to these as “inspector cells”. All cells are defined by code, and this code is hidden by default; it’s only shown if the cell is pinned or focused. An inspector cell is any cell that doesn’t return DOM. When a cell returns some non-DOM value such as a number, string, object or function, this is displayed by Observable’s built-in inspector (much like a browser’s developer tools).

There’s no way to hide a cell entirely, and that’s mostly deliberate: we want the code to be accessible to readers so they can read it, learn from it, and even tinker with it. We are view-source at heart.

It is often the case, however, that a cell can be useful for implementation without fitting easily into the narrative flow. What I do for these cells is put them at the end under an Appendix h2 header. For example:

A more extreme approach would be to hide the inspector entirely via CSS:

html`<style>.O--inspect { visibility: hidden; }</style>`

But, note that the cell names would still be visible in the left margin, so that might be a little weird.

Another approach is to use viewof to override the default inspector and instead show arbitrary DOM. Kelley van Evert shows how (see the def cell for implementation):

Perhaps the cleanest approach is to use imports. If you break your notebook into two notebooks—one explanatory, mostly Markdown and narrative; the other implementing the chart (possibly exploratory)—then you can import the chart into your explanatory notebook without needing to also show those implementation cells. The import statement would be visible, however, so you can’t hide the code entirely!

In the future, we might formalize the concept of an “appendix” (or perhaps an “implementation section”), and allow that section to be collapsed by default. Or we might go so far as to make notebooks hierarchical, and allow you to embed notebooks within notebooks…

In any case, we’ll try to find a nice compromise that makes the code readily accessible without getting in the way of the narrative.


Thank you for the advice. I appreciate that you guys are thinking deeply about these issues. I think I’ll give the import option a try. I did not realize that was possible!

1 Like

That’d be great, thanks!

What do you mean? Just asking for clarification… How is that different from importing notebooks named cells like we already do? How that could solve the “problem” of hiding implementation code?

PS: This is my first post, so I take the opportunity to thank for your stunning work! Observable is just what I needed since don’t know how much time!

1 Like

Is there any update on this? It’s a neat platform to do a JavaScript dataviz blogging. But, it’s quite a turn off for readers who don’t want to know the code.

As stated in the original post:

I’d say this has been largely accomplished by Observable’s embedding features. This gives easy access to an iFrame like this:

If you want the content served by Observable, you can always use the link in the iFrame, like so:

Personally, I think it would be a mistake to make any changes to facilitate the hiding of code within Observable notebooks. As Mike said:

Well, not sure where the direction of this platform will be. To me, I would like to share my interactive dataviz and blogs to other platform like Facebook, twitter, LinkedIn etc. Hopefully, some statistics such as view count and read time. Just like the Medium platform with a built-in code editor.

As JS or D3 programmer, the view-source is useful. But to most people, it’s distracting. Glad to know the iframe exist. Now, I can share it to the Medium and write the post there. I just kinda wish that I have that option here.

1 Like

Yes - from my perspective that’s exactly who this site is for.

On the other hand, the sharing tools (which are under continuing development), could certainly improve. I just (temporarily) posted this link to my Twitter account and, while it basically work it is admittedly not as slick as it should be.

@tophtucker @mbostock Perhaps the embedding tool could more fully address this issue by including appropriate meta tags (like OpenGraph, Twitter card, etc) in output?

One workaround is that at your entry-point, you can run a for…of loop on all elements with class name “observablehq” and from there you can use conditional statements to apply styles such as = “hidden”. I was able to hide cells using a setTimeout to run the above logic as the callback after 2 seconds.

Custom social tags and analytics was the motivation for Example Custom Embed / Endpoint Services / Observable