Pluto.jl icon indicating copy to clipboard operation
Pluto.jl copied to clipboard

file browser behaviour: silent new notebook, path dragging, and landing page linking

Open AshtonSBradley opened this issue 2 years ago • 4 comments

I have some feedback from teaching a 300 level course using Pluto in 2021/2022, to do with the behaviour for opening files. I am happy to try to contribute to any of these that seem useful (although Pluto internals are a mystery to me).

First, I personally don't mind that Pluto has a fairly basic interface for file opening. However, in the absence of a point and click menu interface, I think what one would most like is to effectively utilise the operating system file browser to open notebooks.

Here are a couple of current behaviours that I think interfere with this expectation in unhelpful ways, and suggestions for fixes:

  1. A student this year noted that you can drag a notebook onto the Pluto landing page and it opens. This is great! The trouble comes when you realise (possibly after you have closed it) that you aren't editing the file you dragged, but that Pluto has silently created a "new notebook" containing that code (with random whimsical name). To not lose your work you should realise that you need to save it somewhere... using Pluto's file interface (it otherwise gets a random name on the recent list, so its not entirely lost once you realise this is what happened, but the experience is one of loss!). So you almost got to only use the OS file browser, but then at the end you had to start typing paths into Pluto once again.

It seems to me that the most natural thing to do that doesn't run the risk of confusing the new user or losing work is to open a Pluto notebook file that is dragged onto the Pluto landing page as it is, where it is.

  1. Similarly, dragging an existing notebook into the path bar on MacOS (a fairly standard thing to try) has the effect of pasting all the notebook text verbatim into the path bar (!). As far as I can tell, this is not going to be desirable behaviour in any situation.

The expectation, on MacOS at least, is that the path and filename for the notebook would be injected into the path bar, either auto-opening, or allowing the user to open the target file with one click.

  1. Finally, I think the idea that you can click on the Pluto.jl logo in any notebook and get the landing page is great. I just would like to request that it is stated loudly at the top of the documentation: "click on the Pluto.jl logo in any notebook to go the Pluto landing page" seems so obvious when you are thinking of it as a webpage, but it isn't immediately obvious to many new users (myself included - it took me a while to realise this was the main pathway back in an active notebook) who are prone to assume it is just silent branding.

Not sure what the fix is for this one TBH... I feel like maybe a screenshot of the landing page, and of a new notebook, with some text+arrows pointing out the function of the obvious elements?

AshtonSBradley avatar Mar 21 '22 20:03 AshtonSBradley

Check this somehow related discussion: https://github.com/fonsp/Pluto.jl/discussions/1970

As I wrote there, I believe that it is not possible from javascript to get information on the path of files that are dropped onto the Pluto welcome page, just on their name/contents (see https://stackoverflow.com/questions/15201071/how-to-get-full-path-of-selected-file-on-change-of-input-type-file-using-jav).

I am not an expert on javascript though so there might be ways to circumvent this

disberd avatar Mar 22 '22 11:03 disberd

This is really great feedback @AshtonSBradley, thanks so much!!

fonsp avatar Mar 24 '22 12:03 fonsp

The difficult file system UI is because of browser security: we want to use the native file picker, but we also need to know where the file is, so that:

  1. we can write changes back to the file
  2. we can set the pwd correctly, because you expect commands like read("./data.csv", String) to work

The first one, we can implement on Google Chrome (#833) (but not Firefox...), but the second one is fundamentally impossible.

So our options are:

  1. Implement a point-and-click file browser ourselves inside the browser, but this is really difficult to get right. I think the only way to really make this work is with the native file picker, where your folders are exactly in the place where you always have them.
  2. Make Pluto a native app, using Electron. This is really my favourite, because it gives us the native file system for opening files, but also for saving files and for drag-drop. Even better, this means that you don't need to install Julia, then run a terminal to install and run Pluto, but you just double click the Pluto app!

This second item will take some work, but we want to get it done before the Fall 22 semester. We have a GSOC project about this: https://julialang.org/jsoc/gsoc/pluto/#electron_app , and we already have some applications coming in!

EDIT: See https://github.com/JuliaPluto/PlutoDesktop

fonsp avatar Mar 24 '22 13:03 fonsp

wow this is super exciting!

AshtonSBradley avatar Mar 24 '22 20:03 AshtonSBradley