Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have a more consistent UX between Notebook v7 and v6 in the file manager. #6397

Open
fperez opened this issue Oct 30, 2021 · 16 comments
Open
Milestone

Comments

@fperez
Copy link
Member

fperez commented Oct 30, 2021

Problem

For users transitioning from Classic to Lab-based tools while seeking to keep their existing experience (such as we are looking for in berkeley-dsep-infra/datahub#2422), having a consistent UX from Classic to Retro is very important. In our case it's doubly so given the introductory educational context.

To facilitate this, the Retro file manager should match the UX of classic as closely as possible. A few things come to mind from a quick check, but a more thorough audit should be done:

  • Offer the checkboxes for multi-file actions. Multi-file operations are possible with modifier keys, but that UX is less discoverable than visible checkboxes, and may pose challenges on mobile devices or other scenarios. It also may present accessibility barriers that the checkbox solves. This should also include the top checkbox with a drop menu.
  • The breadcrumbs in Retro should be clickable for navigation, as in Classic.
  • The Retro browser should show file size.
  • This one is controversial enough (I'm not even 100% sure it's the right thing to do) that I'll open a separate issue for it so it can be discussed on its merits: switch the retro browser to acting on single rather than double clicks...

This list is just a start from a quick review, but overall having as close UX parity as possible in retro would help us tremendously in considering the move of our courses to Retro.

Thanks!!

@jtpio
Copy link
Member

jtpio commented Oct 30, 2021

Thanks @fperez for raising these points.

A rework of the file browser has been a long standing issue in JupyterLab. Ideally many of the items mentioned above and in #6396 could be implemented in JupyterLab so Retro could just consume the package, and optionally make some minor tweaks.

@fperez
Copy link
Member Author

fperez commented Oct 31, 2021

I realize this is a tricky one b/c it may require a lot of reimplementation that doesn't seem particularly interesting, just to meet a particular UX that happens to be now ingrained in people's habit from a decade of usage. But I think it's an important one for us to provide a path forward to the community, so hopefully we can make progress on it. Thanks for your efforts!!

@tonyfast
Copy link
Collaborator

tonyfast commented Nov 17, 2021

to track the nearness between the file managers, i put together side by side comparisons. i'm sharing the comparison below from this original hackmd comparing retro and classic

to me, the file/help menu at the top is a great addition from retrolab. some of the sections right now lack anything to click on, but with some curating this is going to be a great new feature.

file browser

header


header additions

  • top menu

    currently the edit, run, and kernel have no calls to action (they might need to be deactivated)

header omissions

  • quit & logout moved to file menu

files/running tab


file/running additions

  • quick access to notebooks and files

file/running omissions

  • cluster tag (this could be a place to land the dask extension)
  • upload compacted to a symbol (the hover text is very nice, but hard to screen capture)
  • new dropdown

file browser


file browser additions

  • filter
  • multi-select with ctrl+click

file browser omissions

  • checklist
  • fiile size

@fperez
Copy link
Member Author

fperez commented Nov 17, 2021

Thanks @tonyfast for these comparsions! I want to highlight a point you make about some of the new features coming from Retro: that's awesome and we should not be shy about keeping those! We want to make sure that things don't change in ways that break existing habits/documentation gratuitously, but improvements to the usage and experience are very much welcome, and expected as they would be in any version update!

These can be seen as much as improvements coming from RetroLab as coming with the new version 7 of the notebook :)

@jtpio
Copy link
Member

jtpio commented Nov 18, 2021

Thanks @tonyfast for these comparisons 👍

some of the sections right now lack anything to click on, but with some curating this is going to be a great new feature.

jupyterlab/retrolab#289 should help remove some noise from these menus, and lay the foundation to more easily customize the menu entries and their order by editing the settings file:

https://github.com/jupyterlab/retrolab/blob/3b9b2bb17c6a87946bb3100a9210bb43eb32b2ce/packages/application-extension/schema/menus.json#L1-L24

@gabalafou
Copy link
Contributor

Hey, dropping in out of the blue. @tonyfast pointed me to this issue and said go! 😄

File checkboxes

So I thought before writing too much code, it might be a good idea to throw up some work I've done so that we can get an initial reaction:

http://gabalafou.com:8888/lab
password hints: starts with an i, was predecessor to jupyter, but all in lowercase this time

screen shot of the file browser, this time with checkboxes next to the files

Most of the UX decisions come from the Windows file browser, like using control + up/down keys; hiding the checkbox unless hovering; and more.

What works:

  • Toggle-all checkbox at the top
  • Checking and unchecking files (in conjunction with the toggle-all checkbox)
  • Using the keyboard to select files: ctrl + , ctrl + , and space bar
  • Selecting multiple files via checking boxes + certain commands (for example, duplicating multiple selected files at once)

Broken:

  • Using shift key for multiple select in conjunction with ctrl + arrow key
  • Edges (such as cycling the focus index to bottom when upping from the top, or to the top when downing from the bottom)
  • File status indicators too close to checkbox
  • and lots more

The code is up on my fork, for the curious, but it is far from ready for review.

My goal is to try to get a sense of whether or not this interaction is worth spending the time to put into good code, as opposed to the slap dash code in my fork. Or if we want a completely different interaction.

@fperez
Copy link
Member Author

fperez commented Feb 11, 2022

I just wanted to say that UX-wise, I love this, and I hope it makes its way into lab proper, not just retro! This makes it much easier for new users to discover how to do multi-file operations, particularly for non-contiguous selections.

Thanks for the work pointing in this direction!

@gabalafou
Copy link
Contributor

That's encouraging. (Impressive turnaround, much appreciated, thank you!)

Do you think these next steps make sense?

  1. Fix the known issues with the demo, then show it to the community at the Wednesday JupyterLab team meeting to see if it's generally well received. If so, then
  2. Make the code more readable/testable/sustainable and put it up for review

@fperez
Copy link
Member Author

fperez commented Feb 12, 2022

I can't speak for the team, but to be honest, unless you're "in the zone" with this code right now and have free time, I don't think it's critical to do much right now before feedback. I do think showing it next week at the Lab meeting would be ideal, and based on that (or other feedback you might get here in the interim), then you'll know if the idea has legs.

I personally love it, but I don't want you to burn time on it if the rest of the team prefers a different direction.

For the sake of feedback, some reasons I like it:

  • discoverability: I think this is a big win for less experienced users when they need to do multi-file operations in Lab.
  • consistency with the classic notebook experience: I'd actually quite missed this when I made the transition, as I always found the checkbox-based approach to be very effective. Gmail has it to this day and I use it all the time.
  • speed for all-files selection. It's much better, and guaranteed correct to grab everything in a folder, to click a single box than select first, scroll down, hold shift, select last...
  • I think it's an improvement for JupyterLab across the board, not just for retro.

I hope this helps support the idea, thanks again for the great work!

@jtpio
Copy link
Member

jtpio commented Apr 3, 2022

File checkboxes

For reference there is now a PR opened in the JupyterLab repo: jupyterlab/jupyterlab#12299

This looks great, thanks @gabalafou for starting it!

@jtpio
Copy link
Member

jtpio commented Apr 4, 2022

Some incremental improvements to the file browser toolbar coming in #6336:

image

@jtpio jtpio changed the title Have a more consistent UX between Retro and Classic in the file manager. Have a more consistent UX between Notebook v7 and v6 in the file manager. Apr 27, 2022
@jtpio jtpio added this to the 7.0 milestone Apr 27, 2022
@jtpio jtpio transferred this issue from jupyterlab/retrolab Apr 27, 2022
@gutow
Copy link
Contributor

gutow commented Jun 4, 2022

Please add:
"Close and Shutdown notebook" does not exit the browser tab, but should.

@fperez
Copy link
Member Author

fperez commented Jun 5, 2022

Thanks for that catch @gutow, agreed; this is an important part of the daily UX for notebook v6 users.

@jtpio
Copy link
Member

jtpio commented Mar 8, 2023

Some more incremental improvements landed in 7.0.0a15:

  • styling of the "New", "Upload" and refresh buttons
  • small tab titles for "Files" and "Running"
  • the file name search input is not visible by default but can be added by users to the file browser via the settings
  • add the file size column

image

@andrii-i
Copy link
Contributor

andrii-i commented Jun 9, 2023

Taking in account that we have 2 release blocking issues left, I wanted to align on what has to be done to release Notebook 7. Equivalent UX vs Notebook 6 is an big part of JEP 79. Would you say we have achieved sufficient consistency for the release and can address remaining points post-release?

@andrii-i
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants