WIP: Hiding code blocks (via Custom Views?)

[christhekeele]

Continuing this thread with @josevalim from the forums, I'd like to propose the ability to hide code blocks from view.

My use-case here is playbooks, where once written, the code takes backseat to operational Markdown instruction, Kino input configuration, and rich outputs. Between Apps and Custom view, there is not quite a way to focus a Livebook like this today.

---

Approach

The easiest way (discuss: is there a better way?) to accomplish this looks to be the addition of a new option in Custom Views to hide code blocks.

This PR serves as a starting point around the discussion for that UX: adding a [data-js-hide-code] flag inline with other view options, and naively making the [data-type="code"] [data-p-language] code editor @hidden when it is present (aka when the menu item is toggled off).

---

Problems

Assuming this is an avenue worth investigating, this naive implementation immediately highlights a few UX issues around where and how various UI elements anchored to the code editor appear.

Simple and rich outputs still look good:

However, key contextual elements reliant on hover state become inaccessible in various ways:

1. The Evaluation Button

   

2. The Block Settings

   

3. The Section Insertion

   

Additionally, the Evaluation Status, meant to be shown in the bottom-right of the editor, floats up and over previous section content or the block settings (if forced to be visible) in awkward ways:

---

Solution

I'm not an adept frontend or UX designer, so my 2 cents shouldn't go too far, and I'm not up to the task of implementing this. But in my mind, a satisfactory solution would be if, when code blocks are set to be hidden:

• Forcing the Evaluation Button to be permanently visible, and perhaps a hair larger
• Floating the Evaluation Status immediately to the right of the button
• Hovering in Section Insertion as normal, inline with the button, in the center
• Having Block Settings appear on on the right as normal, on hover over output or this button row in general

---

Other thoughts

Open to thoughts and other completely different ideas for implementation!

A nice-to-have might be to have a way to exit hide-code mode, or have an individual temporary override toggle per code block cell, right there—either in the Evaluation Button dropdown, or in the Block Settings on the right as a new element.

If this toggle were moved into the Block Settings, it might make sense to always leave that as an option, for temporarily hiding the code editor in any context. How this would interact with a Custom View option merits more consideration, and we could perhaps redirect this effort to simply focus on per-cell hiding behaviour. However, my use-case does want a really easy, single-button, holistic control over hiding code blocks. But maybe we start smaller?

[CLAassistant]

All committers have signed the CLA.

[jonatanklosko]

One approach I can think of is allow a view where code cells are collapsed similarly to the Setup cell. So there is still a visual indicator of cell being present and hovering over to evaluate and perform actions works, but the code itself is not shown. We would then show the code when entering insert mode, similarly to markdown cells. What do you think?

[hugobarauna]

@christhekeele I'm wondering if a custom view like that would be better for the playbooks use case than a Liveboook app. Let me explain why.

For the playbooks use case, do you think the notebook's execution would need to be paused based on the value of a Kino input? For example, if a certain Kino input is blank, the notebook asks the user to fill in the input and pauses the execution until the input is filled in.

Livebook has Kino.Interrupt!/2 for that need. However, it behaves differently in a Livebook app than in a notebook. In an app, there's no way to skip an interrupted cell unless the interrupt functions stop being called (like in a conditional). But in a notebook, it's possible to "skip" an interrupted cell by just clicking "evaluate" in another cell below the interrupted cell.

What occurred to me is that maybe a "don't show code custom view" could be trying to mimic too much the behavior of a deployed Livebook app in a way that, depending on the use case, it may not make sense to have a custom view for that.

But I can see how the other solution for the use case (using a Livebook app) may require more work for the app developer because now they'd need to use Kino.Markdown for the text parts of the notebook/app instead of just a regular Markdown cell.

[christhekeele]

@jonatanklosko One approach I can think of is allow a view where code cells are collapsed similarly to the Setup cell. So there is still a visual indicator of cell being present and hovering over to evaluate and perform actions works, but the code itself is not shown. We would then show the code when entering insert mode, similarly to markdown cells. What do you think?

I honestly would quite like that DX when developing Livebooks, playbook-goals aside!

@hugobarauna What occurred to me is that maybe a "don't show code custom view" could be trying to mimic too much the behavior of a deployed Livebook app.

I do feel a little similarly.

But I can see how the other solution for the use case (using a Livebook app) may require more work for the app developer because now they'd need to use Kino.Markdown for the text parts of the notebook/app instead of just a regular Markdown cell.

This is really the main thing I want to avoid; though José had some ideas in the Elixir Forum thread about maybe making the editing experience of a Kino.Markdown more comparable to that of a Livebook.Cell.Markdown. There are challenges there because Kino.Markdown can be much more dynamic than a static markdown cell.

My other idea was to allow rendering of Livebook.Cell.Markdown in Apps, configurable with a toggle when publishing. This works towards a future where Apps can be published alongside their own static usage documentation, with ToC-navigable headers to break up the form interactions and app outputs, since their static markdown can be known ahead of time.

I started playing around with a PR for that but realized it would take more effort and refactoring, and wanted to get a discussion started. But perhaps it is the better path towards self-documenting playbooks?

[josevalim]

I believe the biggest question we need to answer is: do you want to allow the users to see/change the code or they should never even see it? If they can change the code, add new code cells, etc, then the solution belongs to custom views. If they should never change the code, then the solution belongs within apps.

[christhekeele]

@josevalim The biggest question we need to answer is: do you want to allow the users to see/change the code or they should never even see it?

Currently in the playbooks I've built, for trusted technical team members, toggling code visibility is sufficient. Mostly, there is a lot more Kino code than anything else in there I don't want folk to have to parse when just trying to operate rich Kino outputs under pressure. The ability to open up a block and tweak it would still be useful to them, so that's what I've focused this particular feature discussion on.

@jonatanklosko's idea of granting the setup cell's ability to collapse to all code blocks, with a global collapse/expand all toggle somewhere, is honing in on what that use-case wants, in a way still useful to most Livebook users.

---

However, I do think there's a lot of potential to use Livebook to build internal tooling/playbooks for trusted non-technical team members where the app use-case would really shine. I'm starting to tinker with some of those, and that's what prompted this discussion originally.

There's a lot of manual customer implementation/administration workflows in our org right now, owned by engineering teams without experience or bandwidth to build web UIs to empower the implementation team. Right now non-technical team members are executing python scripts in docker and I really wish I could ship Livebook Apps to them, with baked in service user credentials set up for our systems, rich instruction, and header-based hierarchical navigation through a variety of related utilities in the same playbook, ideally each forking off of some initial Kino setup inputs (unsure if that's possible in Apps today).

I'm happy to break that off into a separate PR/discussion, though, because I think there's utility in just the code block toggle as well.

[josevalim]

So with that said, doing something like "Collapse code cells" could work out, and we treat them as the setup one, as proposed by @jonatanklosko. Are you happy with that, @christhekeele and @hugobarauna?

[jonatanklosko]

@josevalim to clarify, the difference from setup cell would be that focusing the cell would keep the code collapsed, only entering insert mode would show the code. (I mean, we can do either, but for @christhekeele use case we probably don't want to expand the code when someone clicks "Evaluate" and focuses the cell)

[josevalim]

Could we instead make it so clicking on it makes the code appears but we skip them when using navigation?

[jonatanklosko]

If we want to distinguish click I would make it more explicit, perhaps a pencil icon like the markdown cell, or some button in the collapsed placeholder, like "Collapsed cell [Edit]".

[christhekeele]

for @christhekeele use case we probably don't want to expand the code when someone clicks "Evaluate" and focuses the cell

If we want to distinguish click I would make it more explicit, perhaps a pencil icon like the markdown cell, or some button in the collapsed placeholder, like "Collapsed cell [Edit]".

Yep, evaluating without expanding would be my preferred UX for developer-oriented playbooks. A separate control for that would be perfect.

Are you happy with that, @christhekeele and @hugobarauna?

Personally, @hugobarauna has convinced me that there's still value to be had in getting markdown into apps for non-developer-oriented playbooks. I know you touched on some ideas there in the forum thread, but that's another discussion/PR/issue at this point.

But what we've discussed here sounds like exactly what I want for my playbooks today, I am happy with the proposed UX for Livebook code hiding controls here!

[hugobarauna]

I'm happy with the final idea as well.

I understood the solution would be a new custom view where:

• code cells are collapsed by default
• navigating through cells doesn't open a collapsed code cell
• to open/edit a collapsed code cell, the user can click a button/icon
  • maybe the i keyboard shortcut for "Switch to insert mode" code could also open the collapsed code cell, the same behavior with a focused markdown cell in navigation mode