Pluto.jl: Why is cell output above code?

[briochemc]

I find it confusing to see the output above the code in each cell. Could you explain the motivation behind this design choice?
Maybe a nice feature would be to be able to have the output below the code?

[karlwessel]

Although I'm fine with how it currently is, I would also like to know the motivation for this design decision.

My interpretation is, that it emphasises the point that the output/value of a cell is more important than how it was produced. I regard the code of the cell as a more detailed description of the output/value, which I can read after I have seen the output. If the output is enough I can decide to skip reading the cell code, which is easier when I have already seen the output.

I guess that reasoning is similar to the reasoning behind figure captions in papers always being below the figure. Ideally the figure should transport all information necessary and I can skip the caption, but if not there is the caption to answer details about the figure.

But maybe I'm interpreting to much into this :).

[fonsp]

The motivation that @karlwessel pointed out is exactly right: output is the primary element in Pluto notebooks, and the metaphor of figure captions is also what I have in mind.

Related to this: we think that hiding code is a great way to have a development environment and a readable document in one. For example, you use markdown to write formatted text, and you then hide the code.

This makes it common to switch between folded (hidden) code, and unfolded code. This changes the total _cell height_, causing the page to shift vertically, which is a disorienting experience. If the cell output would be on the bottom, the output would also jump up, causing most of the content on your screen to jump position. When most of the screen jumps, you might have no point of reference to understand where you ended up. When the output is on top, it does not change position when you fold code, making the reflow less jarring. The designers of observablehq have also made this design choice to solve this jumping problem - I learned about the solution from them.

There is another trick in Pluto to prevent sudden vertical shifts: sudden changes in cell output height are measured (e.g. when a cell suddenly errors, the output becomes a large stack trace), and the current scroll position/focused element is used to decide whether this shift should be compensated for by scrolling the page. If it works, you should never notice it :)

[fonsp]

We are still thinking about the layout, and we have some experiments on where to place output, some of which are here

[karlwessel]

There is another trick in Pluto to prevent sudden vertical shifts: sudden changes in cell output height are measured (e.g. when a cell suddenly errors, the output becomes a large stack trace), and the current scroll position/focused element is used to decide whether this shift should be compensated for by scrolling the page. If it works, you should never notice it :)

Yeah, regarding that: I think this broke again in the new release. My browser is jumping occasionally when i mark cells (If you don't already have an idea where it comes from I'll try to provide a more detailed MWE when I have time later).

[briochemc]

Thanks for answering @fonsp!

FWIW, what confuses me is that when writing (editing) a notebook, the flow is not linear anymore. I love jumping up and down to change values and see the effect in all directions when I'm demoing or testing stuff, but not when I edit the notebook's text and write code. For example, I write some text, then I go down to write some code expression and evaluate it, and my eyes naturally go just below expecting the result there. This is likely because I am used to that linear orientation and dynamic. At the REPL, in Jupyter notebooks, including other programming languages, and even when you simply write text, you essentially type down your ideas from top to bottom. (I'm not talking about when you reorder things, and this is beautifully handled by Pluto's intuitive UI with the ability to move cells around anyway.)

A solution/feature that may be useful IMHO would be having a button to trigger an editing layout with the output below, and the standard layout as it is with the output above. What do you think?

[fonsp]

(@karlwessel a mwe would be helpful if you have time!)

[Pocket-titan]

I think the main reason Pluto shows output above the code is because its main inspiration is Observable (https://observablehq.com), which does this too. But seeing as Jupyter & Colab (to name a few) show the output below, and many Pluto users will likely be coming from these platforms, perhaps adopting that layout would be more intuitive? Or perhaps an option to switch between layouts (above/below) could be useful?

[fonsp]

(Observable was the inspiration, but not the _main reason_ for choosing this behavior. I did consider both sides, and I have explained my arguments in my earlier comment.)

[Datseris]

Although your arguments are sensible, I think the option of choice of having it below is a benefit. Depending on the programming background level, the viewer/user might be spending let's say 90% of their time writing Julia code and/or scripts, and 10% on Pluto.jl creating a report or illustration. Then, the user experiences 90%% of code execution output below commands, and 10% above.

In such scenarios, "getting used" to the inverted layout is not really possible, or at least, not pleasant.

[fonsp]

I agree that it could be useful to have that option, and I think that I will add it - later!

But right now I am in the middle of development, including some experiments about exactly this topic (some of it I wrote down here and here). Adding an option to flip cell input and output breaks up the possible states in two - from that point on I will need to develop & test two different layouts at once. Cell layout is related to many parts of the design, and I feel like having the layout switch will make a lot of future work more cumbersome.

So it's not just designing a settings page, a global settings store and writing switches into the code, I am mostly worried about the maintenance cost after it is implemented. I understand that this is not what everyone might want to get out of the project, but for me, Pluto has to remain something that I enjoy working on.

[cenkt]

IMHO and coming from Jupyter environment downward flow fells more natural both mathematically and physically. We are accustomed to read from top to bottom and solve equations from top to bottom. So best solution could be an option for the user to choose. Nevertheless this look like a good new improvement on notebook coding environment.

[shorca]

Just want to offer my two cents: I love the output on the top. One annoying thing in Jupyter is that when the cell is at the bottom, the output of the cell will be below the bottom, requiring me to scroll down to see it. In Pluto, it is a non-problem.

I also wholeheartedly adore the motivation that "the output is more important than code"!

[mkborregaard]

To be fair, I don't think familiarity is a very strong argument for anything. Particularly if you want to rock the boat, which Pluto definitely is doing very successfully.

("Look, my setup works for me. Just add an option to enable spacebar heating" https://xkcd.com/1172/)

[PToTheK]

@fonsp
At wich code position is defined that the output goes before the input?
I would like to play a little bit with different solutions.

[Datseris]

@PToTheK , thanks to Mason Protter: https://github.com/MasonProtter/Pluto.jl/commit/7dea5605689ff03468a245c2c828e15f6c19d688

(edit: I am impressed by how little code change is necessary for this to occur)

[MasonProtter]

@PToTheK , thanks to Mason Protter: MasonProtter@7dea560

(edit: I am impressed by how little code change is necessary for this to occur)

Just to clarify, it was @EricForgy who found that tweak. I just packaged it.

[PToTheK]

@Datseris, @MasonProtter thank you very much.
This looks much better to my eye! Thats the right flow to read and understand code!

[waldyrious]

Just to add another 2¢, I personally quite enjoy the side-by-side layout of some literate programing tools, e.g. pycco, as well as documentation platforms like slate. A design that makes the cells more evident with subtle separator lines and a highlight-on-hover effect can be seen in this (somewhat broken) page.

I noticed this was one of the layouts considered in the Notion document, but since no one had expressed preference for it in this thread, I thought I'd mention it.

[RaulDurand]

An option to switch between layouts (above/below) would be great.