notebook icon indicating copy to clipboard operation
notebook copied to clipboard

Reconsider single/double click behavior in the Notebook v7 file manager

Open fperez opened this issue 2 years ago • 0 comments

Problem

As I mentioned in jupyter/notebook#6397, I think that for users who come from Classic to the Lab-based toolchain but are looking for a similar experience, the switch from single- to double-click behavior in the file manager is going to be jarring.

So I would like to have this issue for discussion of the problem, though I know this is a tricky one. Other aspects of UX parity I think are straightforward and simply a matter of implementation.

The pro argument is consistency with transition from Classic, the con one is that this really would be a big break with the behavior of Lab... I just checked what VSCode does, and it has an interesting behavior that I actually think works well (though it has an annoying inconsistency): single click opens files in a quick preview mode, but you need to double-click to leave it permanently open for editing.

The inconsistency in vscode is that some file types (like PDFs) do stay open on single click, I think the distinction is whether the file is editable or not.

I'm leaning towards the view that a more consistent version of the vscode behavior could be a good solution across Retro and Lab:

  • single click does something useful immediately:
    • in Retro it fires a new tab (like Classic)
    • in Lab it opens the file in a quick preview mode (i.e. no kernel for notebooks, no render for markdown, etc). If the user clicks on a different file, it previews that one in the same tab, so the single-click action can be used to quickly "scan" a folder with many files. A file opened for preview with a single click becomes "fully active" if the user edits it while they had it open in the preview tab.
  • Double-click works like it does today in Lab, no change there, and can also work the same for Retro, to help with consistency.

A bit controversial perhaps, and would need discussion in Lab as well, obviously, but I'm warming up to this as both a good transition option for Classic -> Retro in a critical part of the UX, and actually an improvement to the Lab UX (to this day I still don't like the double-click behavior of Lab, TBH).

Obviously something could be implemented here independent of Lab, but I think we should consider these decisions holistically to provide as smooth as possible an experience from classic to retro to lab.

This is also relevant to our work in berkeley-dsep-infra/datahub#2422.

fperez avatar Oct 30 '21 05:10 fperez