Side panel proposal

[josevalim]

Hey guys, thanks for the amazing work you are doing here. I truly appreciate it :)

I had a similar concern, which Jose pointed out was being discussed here.

Given that it's stiiiill not merged, I have a UX proposal for your consideration:

PROBLEM: It was my experience, learning Ash framework using their Livebook tutorial series, that most of the output felt too verbose, and it was a detriment in the top to bottom reading & learning experience. I often would rapidly scroll up and down avoiding the code results, and I see this particular issue is not being addressed by the current implementation.

(POSSIBLE) SOLUTION: Add a block feature flag that indicates how a particular block should render by default (settable also on a per Livebook basis). This way Livebooks authors can decide as a blank statement, how the document should be read, but also giving the reader the possibility to revert the author's decision.

By choosing "Sidepanel" on the added options to the dropdown on the image above, what I'm intending to happen is: when you press (re)evaluate, still print something downwards, but make it as minimal as possible while still making it expandable on command.

To achieve this, you'd need a new toggle state for what I'm calling bottom results. For that, here's a solution that comes in handy, even if you don't implement the proposed solution to the original problem (Reader can hide output):

With all this in place, when running an evaluation that had "Sidepanel" as it's output option, readers would see something like this:

Originally posted by @fceruti in #2109 (comment)

[josevalim]

I moved the discussion here to avoid side tracking the PR.

[jonatanklosko]

I don't think this fits into the purpose/design of the side panel, so I would consider it separately. We can do one of the following:

1. Have a new View, where code cells are always half-width and outputs are on the right.
2. Make all outputs collapsible (similarly to how we collapse sections).
3. Have per-cell configuration that says if the output should be collapsed. Though in most of such cases it's likely the output is just not relevant and the cell could just return a less verbose value.

Which one is better depends on the actual problem we are trying to solve, 1. makes a better use of wide screens, especially that code usually that wide. 2. is more specific to the use case where we want to run everything and collapse all outputs, then only expand outputs that we are interested in.

[josevalim]

I am more inclined towards 1. If you want to collapse outputs, we should rather have custom kinos. I would not necessarily make it a property of Livebook.

[fceruti]

Improving upon 1, I'd suggest create a bigger waist where the code/result goes. Something like this:

[Thorhian]

I was just thinking about the possibility of side panels, but for documentation. The hover docs and notices are nice, but it would be cool to allow displaying docs on the side as well (and an implementation of K in the vim emulation to pull up docs) instead of having to to pull them up in separate tab in hexdocs. This output on the side seems like a really good idea though.

[dkuku]

My 2c what I think may be useful. A panel in the dev tools style that always at the bottom:

• I was reverse engineering a camera that has a soap interface and can send callbacks-it would be useful to log the callbacks
• using telemetry events in livebook and see the output in realtime
• any other async task output