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

[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/)

[pkroenert]

@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: MasonProtter@7dea560

(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.

[pkroenert]

@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.

[clason]

I hate to plus-one such a well-hashed issue, but there's a suggestion I haven't seen mentioned yet and would like to add:

Can you add a "Preferences" menu to notebooks with a toggle "Output below code" (which is fine with me to default to "false")? You already have a similar thing with the new export menu, and such a "cogwheel" menu can later be extended with other options that make sense.

---

This adds nothing to the suggestion, but I'd like to mention why I'm so keen on that option: For my use cases, code is indeed the primary object, and the output is just one example illustrating that the code works. (I'm well aware that this is not the only use case and that it's just the opposite in other, equally valid, use cases!) Hence having output before code is a massive break of causality and adds -- again, for me -- significant cognitive load. The related argument for fixed execution order is not quite relevant here because there I have the choice to just use linear cell order and avoid the more complex dependency detection Pluto.jl offers. (The new feature of disabling cells is an excellent compromise for that, by the way, and really well implemented!) And I would like to have a similar choice on the "micro level" as well.

[holomorphism]

@clason You might be interested in @disberd's solution.
https://discourse.julialang.org/t/ann-plutostyles-jl-override-styles-of-pluto-notebooks/64280/33

[yarkun]

Personally, I find the current layout (output above input) extremely counterintuitive and distracting, because it puts the effect before the cause which is exactly the opposite of our experience in the real world.

The argument about the output being more important than the input is

1. not true for most of the use cases; input and output in general should be equally important, otherwise there would be no need to use a tool like Pluto that presents them together. (This, btw, is a good argument for adding output folding. Sometimes we don't need to see the output either.)

2. in any case does not imply that output should be placed above the input since putting output above does not make it any less or more prominent on the page.

Also, the argument about layout elements shifting when one of them changes in size applies to all layout choices, e.g., currently, when the output appears on the page or changes after an input edit, everything below it, including the input that we are working on, shifts up or down, which is equally jarring.

[RaulDurand]

Hi!, Any update on this?

[xgdgsc]

Not likely "one day" would come. I would like to recreate something more condensed like the Juno experience as #2357 described if I have time, while I' m currently using my fork of vscode extension that has Pull Request #3123 · julia-vscode/julia-vscode combined with RemoteREPL.connect_remote in jupyter notebook to minimize need of notebook features. It' s a pity Neptune.jl is unmaintained.

[pankgeorg]

You can use @info or println to print below the cells and append ; to suppress output, if you prefer that style. Other than that, maybe Pluto is not the right tool for you.

[bdklahn]

@pankgeorg Opt to use a completely different tool, vs. just have a configuration option for this??? I'm hoping this sort of thing would be trivial, for a software developer. -unless we want to communicate to new users that Julia and/or this software wasn't designed to make it easy to do something like that?

I've always found it very inefficient, uncomfortable, and unnatural to have to visually scan down, then back up, then down, then back, up. Maybe, in something like a final publication, it makes sense to add some "how I got to this", as a caption, under some output. But, there, the assumption is that the result can stand alone as an explanation. That is usually not the case in the context of a notebook, where one is experimenting. In a notebook it's "Okay. I did this, I got that. I did another thing, I got this other thing.,etc.". It flows along, cause and effect, over time. With a fully developed publication, like a research paper, perfect linear flow doesn't matter as much, as sections are separated to enable people to jump to where they need/want to go. A notebook is not that. I'd say the default option should be to have output after input. If one wants to develop a notebook to the point of "publication grade", then maybe flip the option. But, in that case, if you want "interactive, presentation grade", then you might want a full dashboard or multi-page web application, where you can, at least, easily layout content in more than just one column.

[pankgeorg]

Hello! Thank you for your time writing a reply. For a technically trivial solution, see disberd's css display fix from above. It should work for you too. If you remove the "[swap_output]" attribute from the CSS, it will work globally. We still don't think a configuration option for this will fix more issues than it will introduce. While other notebook systems take a different approach, Pluto notebooks are supposed to be ready-to-read articles, as you mentioned. For advanced usages you are welcome to override the styles; there are many tricks you can do to customize your experience.

[bdklahn]

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 :)

Here it sounds like you have already solved the issue which was the main reason observablehq and Pluto do it this way.
Wouldn't doing it for the input cell be at least as easy as for the output? It wouldn't have to be a callback to whatever signal happens when output is recalculated. It could just be called when hide or unhide is clicked (with the cell size able to be pre-cached, rather than needing calculation after the output is finished).
I guess I don't know enough about how this code was engineered.
Anyway, I appreciate the time which went into this. I understand if it's not considered important enough for dev time.

[bdklahn]

Hello! Thank you for your time writing a reply. For a technically trivial solution, see disberd's css display fix from above. It should work for you too. If you remove the "[swap_output]" attribute from the CSS, it will work globally. We still don't think a configuration option for this will fix more issues than it will introduce. While other notebook systems take a different approach, Pluto notebooks are supposed to be ready-to-read articles, as you mentioned. For advanced usages you are welcome to override the styles; there are many tricks you can do to customize your experience.

Thanks for your time in responding, and for re-pointing that css setting out. That might be a simple thing I could leave in a fork of this.

A Pluto notebook, currently, looks pretty far from an "article".

These notebook systems were originally designed to mimic scientific lab notebooks, with added live interactivity.
When a scientific article was to be authored, based on information from notebooks, etc., it would look less linear than a notebook (typically single column, chronological progression, top to bottom). Doesn't Pluto only support a single column of output, out of the box? If so, I'd say it's more natural for folks to assume it's a single, top to bottom, workflow like a notebook, vs. an article. I get that cells can be moved up and down, with the backend still tracking object dependencies. I love that! But the single column layout, and calling it a "notebook" vs. maybe a "book", seems to imply the default behavior will be code, output, code, output, etc. . . .

I would LOVE for a notebook system to present seemlessly as a one-page web app. Those look more like articles, where text can flow around figures, etc., placed anywhere on the page.
I'm still hoping for Pluto to be able drag things around, at will, like gridstack. :-)

Oh . . . wait . . . maybe this was done already.
https://www.youtube.com/live/nRmLfB-bKdc?si=uEPLCVWbp5qF5aVd&t=432

Maybe some of this is possible with simple tweaks or html export, or whatever. I apologize if I have missed something.
I really do appreciate the work, and it is a bit unfair for us to complain about something so nice, which we can use for FREE!

[pankgeorg]

Don't worry, I don't mind really (despite the negative reactions in my replies :) ).

This is not really about developer time, or technical complexity. This is about style, identity and support:

• Style because the core team currently feels that this is the way to present a code; HTML on top, side effects (logs and terminal) below
• Identity because we do not make a clone of jupyter
• Support because, since we believe [1] is the way to go, we don't want to spend time fixing bugs around a style we consider un-pluto-y.

Consider asking julia why DataFrames.jl isn't conforming to the pandas API; it's quite similar.

Oh . . . wait . . . maybe this was done already.
https://www.youtube.com/live/nRmLfB-bKdc?si=uEPLCVWbp5qF5aVd&t=432

oh that's me 🙈
This is an early prototype of what you ask above, but it's not close to being Pluto quality to be used upstream. But we may get back to it at some point (I really want to but between then and now, 🧑🏾‍🍼🧑🏾‍🍼happened and I'm low on free time 😞).

We are actually very happy to see forks that test out new ideas and challenge the decisions of the project. Neptune was one, challenging a lot of the decisions, but is unfortunately unmaintained. Jolin.io is less of a "hard" fork per se, but AFAIK, https://github.com/jolin-io has a lot of tricks that aren't following 100% what Pluto does per se (see Jolin hooks, which are great, and we'll soon get inspiration from them ❤️!). This creates an environment of cross pollination and really removes some pressure from 5-6 people. That's what Open Source is about; the fact that a feature is not something I want to pursue, doesn't mean that is not worthy. But also, the fact that is is worthy for some people doesn't mean that I must work on it (unless, you know, boss comes and says so).

So do fork the project, make a case and we'll be happy to consider reviewing a PR that bridges the two worlds!

[bdklahn]

Thanks for your reply, @pankgeorg ! -and all your good work on this code base!

Of course if the core team feels this way, and are the ones doing almost all the work, that's how it should be done.
Keep in mind that choices which are out of sync with common logic, are likely to reduce adoption (and, correspondingly, fewer contributors). If you post a poll you could determine which way is preferred. Then you will at least know how much you are tending towards targeting Pluto to a broader usage, vs. targeting usage mainly by Pluto core developers.

• Style because the core team currently feels that this is the way to present a code; HTML on top, side effects (logs and terminal) below
  I just think it's more natural (and easier for humans AND machines/code to undertand/read) if things are cleanly separated by input and output. HTML rendering is one of the output side-effects. Currently you are treating one particular output in a trivially special way, by displaying it above the "cause". I think this separate treatment can be both semantically and visually confusing to people. These notebooks can already be "HTML-first/centric", by hiding code (and stdout/err?). You don't really need another way to distinguish/prioritize this.

• Identity because we do not make a clone of jupyter

My point was that this "notebook" isn't, by default, behaving like a notebook, in a key way. That has nothing to do with Jupyter, etc.

• Support because, since we believe [1] is the way to go, we don't want to spend time fixing bugs around a style we consider un-pluto-y.
  I'd say to be careful to define your fundamental software identity (being "pluto-y") in terms of a particular small UX design view decision.

Consider asking julia why DataFrames.jl isn't conforming to the pandas API; it's quite similar.

DataFrames.jl is SOOO much better designed and implemented than Pandas. Pandas was designed
for a limited use case, and then evolved for things it wasn't originally meant to handle. Even the Python
folks are moving away from, or trying to refactor or mitigate around Pandas. Of course, many things can't be "fixed", without moving away from Python's inherent limitations, entirely.
But DataFrames.jl HAS adopted the fundamentally good things about the R.dataframe/Matlab tabular interface, just like Pandas did. It's just like the original Julia creators weren't trying to completely do the opposite of be a "clone" of all the languages: They tried to take the best parts of them, as inspiration.
So I don't know that DataFrames.jl is a good comparison to this.

Oh . . . wait . . . maybe this was done already.
https://www.youtube.com/live/nRmLfB-bKdc?si=uEPLCVWbp5qF5aVd&t=432

oh that's me 🙈 This is an early prototype of what you ask above, but it's not close to being Pluto quality to be used upstream. But we may get back to it at some point (I really want to but between then and now, 🧑🏾‍🍼🧑🏾‍🍼happened and I'm low on free time 😞).

No worries. I thought that functionality was really cool (!!!), and exactly what is needed to get Pluto into the realm of "article" vs. "notebook" (vs. simply making code look like a trival caption, on a figure). I mean . . . currently the Pluto interface is/looks more like a traditional notebook. It is more like Jupyter Notebook, vs. the current Jupyter Lab interface. Jupyter Lab not only has more than 1D in it's "IDE-like" interface, but it can also render/run things more than 1D in it's Voila server, with gridstack template (although, it does seem like development on that part is stagnant). I am not suggesting Pluto should become an IDE. But if the main interaction almost exclusively happens in a 1D space, Pluto is more "notebook" than the current crop of modern notebook interfaces.

We are actually very happy to see forks that test out new ideas and challenge the decisions of the project. Neptune was one, challenging a lot of the decisions, but is unfortunately unmaintained. Jolin.io is less of a "hard" fork per se, but AFAIK, https://github.com/jolin-io has a lot of tricks that aren't following 100% what Pluto does per se (see Jolin hooks, which are great, and we'll soon get inspiration from them ❤️!). This creates an environment of cross pollination and really removes some pressure from 5-6 people. That's what Open Source is about; the fact that a feature is not something I want to pursue, doesn't mean that is not worthy. But also, the fact that is is worthy for some people doesn't mean that I must work on it (unless, you know, boss comes and says so).

So do fork the project, make a case and we'll be happy to consider reviewing a PR that bridges the two worlds!

Maybe I'll have the time, amongst the dozens of other software projects I'm involved in, to look into that code. Probably not.

There are SOOO many awesome things about Pluto. I even just like being able to expand output container objects, etc. But I am surprised how this simple issue does seem to slow my workflow, by causing me to change my context, from where the code I just typed is, to have to scan to file the top of the object above it, rather than just starting to read down from where I already am.

[kdpsingh]

To anyone who comes across this issue from a search engine, here's what you can copy-paste into a code cell in Pluto to ensure that all output shows up after the code.

This is adapted from @disberd's post at: https://discourse.julialang.org/t/ann-plutostyles-jl-override-styles-of-pluto-notebooks/64280/33. This version automatically works on all code cells. The best part is that you can hide this code block so that it's invisible to viewers. Am writing this out here because the answer linked in the Discourse post is in a screenshot, where it is hard to copy-paste.

I'll second the notion of others above that I am really enjoying Pluto and would love to see this option officially supported.

using HypertextLiteral; @htl """
<style>
pluto-cell {
	display: flex;
	flex-direction: column;
}
pluto-cell pluto-output {
	order: 1;
}
pluto-cell pluto-runarea {
	bottom: -17px;
}
</style>
"""

[quantarion]

I don't like either, lol, I'd prefer the output to be displayed on the side...
Ideally the left (cell code) and right column (cell output) would scroll at different speeds to keep cells and their output always in sync , like kompare diff GUI tool from KDE

I tried to do that with the CSS snippet above, but I'm really not a HTML/CSS expert so it came out ugly. I tried to change flex-direction: column; to flex-direction: row;
If someone can make it pretty please post it here!

[quantarion]

I somehow managed to actually make it look almost decent. If anyone likes the idea here's the code:

using HypertextLiteral ; @htl """
<style>

main
{
	margin: 0 !important;
	max-width: 100%;
}

pluto-cell {
  display: flex;
  flex-flow: row;
  flex-wrap: wrap;
  align-items: stretch;
  margin-top: 34px;
}

pluto-input { 
  order: 1;
  width: 50%;
  padding-right: 5px;
  margin-bottom: 5px;
}

pluto-shoulder, pluto-trafficlight
{
  margin-bottom: 5px;
}

pluto-output {
  order: 2;
  width: 50%;
  padding-left: 5px;
  margin-bottom: 5px;
  filter: brightness(1.2);
}

pluto-runarea {
    order: 3;
    width: 95%;
    padding-left: 17px;
    bottom: -17px;
}

</style>
"""

Judging from the comments above, this kind of change in Pluto is smirked upon and never accepted so I wont bother making a new issue. If someone knows how to make cells and their output scroll like in kompare, please let me know!

[quantarion]

It was easier than I thought. After some CSS magic even scrolling works:

using HypertextLiteral ; @htl """
<style>

main
{
	margin: 0 !important;
	max-width: 100%;
} 

#pluto-nav {
	opacity: 0;
	transition: opacity 0.3s ease; 
}

#pluto-nav:hover {
	opacity: 1;
}


pluto-cell {
  display: flex; 
  flex-flow: row;
  flex-wrap: wrap;
  align-items: stretch;
  margin-top: 34px;
  align-items: flex-start;
}

pluto-input { 
  order: 1;
  width: 50%;
  position: sticky;
  top: 0;
}

pluto-shoulder, pluto-trafficlight
{
  margin-bottom: 5px;
}

pluto-output {
  order: 2;
  width: 50%;
  position: sticky;
  top: 0;
}

pluto-runarea {
    order: 3;
    width: 95%;
  	padding-left: 17px;
}

pluto-runarea {
	bottom: -17px;
}

</style>
"""

This is how it looks like

Let me know what you think.

[jemucino]

@quantarion thank you very much for sharing! In my opinion, this is how notebooks should be arranged for development and it's unfortunate that this layout doesn't get a second thought. My primary monitor is more than wide enough for split screen and this helps me focus on source on the left and presentation on the right. There's a reason I prefer editing markdown on vscode with my .md file on the left and markdown preview on the right: it just makes sense!