🏠 back to Observable

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.

https://beta.observablehq.com/@palewire/the-ichiro-bet

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?

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.

https://wpinvestigative.github.io/federal_employees_trump_2017/employment.html

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.

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.

5 Likes

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