"Amplified" smart cells should be full width in Preview/App mode

[elepedus]

Currently, the "Amplify output" button only affects the output within the notebook itself, but doesn't persist when using the preview or deploy features.

This is a bit of a foot-gun, as it allows the user to build layouts which seem great, until they're deployed, at which point they're unceremoniously cropped e.g:

Would it be possible to persist this setting and apply it anywhere the smart cell is rendered?

[jonatanklosko]

The amplification is temporary by design, if you refresh the notebook page it is no longer applied. Technically multiple users can be using the notebook and amplification is a user-specific view adjustment, just like collapsing sections, or using one of the "views" feature.

When it comes to the app, note that the amplification takes almost full width, and width depends on the display size, so even if that was reflected in the app, it may not provide consistent experience anyway.

[hugobarauna]

@jonatanklosko, this is at least the second time I've heard a user needing a wider width inside a Livebook app.

I think this is something we can support.

I don't know the solution, though:

• configuration of the app?
• just two sizes (like Notion pages: default width and full width)
• any other solution

[jonatanklosko]

I think the canvas would solve it, once we introduce it.

[hugobarauna]

Good point.

@elepedus there's a feature we want to have. There's even an open PR for it. Here's a video of how it could work.

Do you think a solution in that direction would fulfill your need?

[rcuevas-wash]

Would like to second the need for way to escape the "notebook layout" and be able to render things horizontally.
100% of my use cases include rendering things that looks like a traditional dashboards with , many widgets presented the long way horizontally.

My current work around is to use a regular phoenix web app with live view to render horizontally, or pass custom css to something like DocRaptor to render my horizontally scrollable table, horizontally and paginated.

[elepedus]

I would settle for the ability to pass an option to a kino that toggles container constraints.

Alternatively, could the Amplify button set a value in the .livemd, which could be picked up during app/preview render to omit the max-width class?

[jonatanklosko]

Alternatively, could the Amplify button set a value in the .livemd, which could be picked up during app/preview render to omit the max-width class?

Whatever is persisted in .livemd is inherently shared across all users, and that's not desired as per the previous comment :)

An option on kino grid could be an option. Though if we go with the canvas, that's probably a more suitable solution anyway.

[hugobarauna]

@jonatanklosko, maybe we could have a solution for enabling full/configured width before having the canvas, depending on how long it will take to have the canvas.

[elepedus]

Is it worth distinguishing between amplification in the notebook view as an ephemeral user choice, and full-width smart cells (Kino Frames/Layouts) as a design decision?

I can see the argument in favour of individual notebook users choosing to amplify or not according to their screen size etc.

On the other hand, once you've build a Livebook app and deployed it to end-users who may never see the inside of a notebook, it's very useful to say "this is a full-width experience".

[jonatanklosko]

So perhaps we should have a checkbox in the app settings that makes the app full-width? @josevalim wdyt?

[elepedus]

I think I prefer this to be a property of the app, rather than something tied to Kino and outputs. We can wait for the canvas, but that's going to take more time, because there are definitely a few other priorities.

How about something like this?

It could toggle the max-w-screen-lg class on the data-el-notebook-content div.

[hugobarauna]

I think I prefer this to be a property of the app, rather than something tied to Kino and outputs. We can wait for the canvas, but that's going to take more time, because there are definitely a few other priorities.

Thought about that, and I think it would work.

And when enabling the "full-widht"config, if the dev still wants to have some parts of the app not to be full-width, they use Kino.Layout.grid like this:

[josevalim]

So only the outputs are full width and not the whole page? That actually makes sense because of the text. But the issue with adding this option is that now we have to resort to grids and it is just a matter of time for folks to ask to have control per output.

It feels the simplest option is to make the "Amplified" a property of code cell, which impacts the default amplification values of its outputs. This way you get your per-cell control, users can control to expand or shrink it, it improves both notebook and app experience, and keeps the settings simple.

[hugobarauna]

So only the outputs are full width and not the whole page?

I was thinking about the whole Livebook app, which may be the same as outputs. I don't know if it is only output because one can render something in a frame in the middle of a code cell.

[hugobarauna]

One of my inspirations is Notion pages (I use Notion a lot). They basically have:

• default width / full width
• columns

People can already do all sorts of different layouts in notion pages just with those two primitives.

We don't have an equivalent of the Notion full width (that's my idea). But we already have an equivalent of Notiion columns, which would be our Kino.Layout.grid/2 with this columns option.

So, adding the "full width" config for a Livebook app (not a notebook) would be already powerful enough to customize its layout.

And in the future, we'll have easier ways to build layout, with the canvas/output feature.