META - Design a better JupyterLab launcher

[trallard]

Background

The JupyterLab launcher works well for traditional workflows where users work locally, more likely within a conda environment (or similar). Thus they'd end up with a handful of kernels (at most).

However, once that workflow breaks, as is what conda-store enables: local or remote development with many available kernels, the launcher becomes unusable by most folks:

• The current card approach (Python or Kernel logo + kernel name) becomes redundant as one cannot distinguish kernels from that context
• As more kernels and environments get added, the cards end up taking all the available space (and are repeated for notebooks and consoles)
• Right now, the end-user cannot customize the launcher to adapt to their needs
• There was a previous attempt at an enhanced JupyterLab launcher, but it is based on the same cards approach, and the significant improvement is achieved by merging the console and notebooks cards (plus it seems to be unmaintained now)

Tasks

Beta Give feedback

1. Define requirements for such an extension
2. Design: wireframes and mockup
3. Dev: extension development
4. Define requirements for user customisation

[pavithraes]

Thanks for opening this issue! We've discussed this a few times, but I did not realize we already had this issue to point folks to. :)

cc @dharhas - so you're notified of activity as this overlaps slightly with discussions in Nebari/JATIC spaces

[dharhas]

I would like to address this in the next JATIC increment.

[kcpevey]

Specific requests that have come up:

• Need ability to Search in Launcher screen for kernels
• Need ability to Search for environments in the kernel selection
• Mike - We can create a workspace which customizes layout. It is saved as a json. We can push this to users so every launch will be the same. Will be in the 4.2 release.

Also relevant: Adding notebook "favorites" in the sidebar will be available in nebari soon

From @dharhas :

[kcpevey]

From @krassowski :

I know that this issue is about redesign, but I will also leave some implementation notes that might help with planning:

• Need ability to Search in Launcher screen for notebooks

Searching for recently used files/notebooks would be easy to implement and might be accepted in JupyterLab core. Searching for arbitrary file on the server which may have hundreds of thousands of files will have a high maintenance cost because it has performance implications (and increases surface for denial of service attacks).

It feels to me that general purpose "search for a notebook" might be better placed in the file browser rather than launcher.

However, searching for a tile in the launcher sounds like be a good idea, especially if the search box was hidden by default (e.g. only showing when user clicks on a discrete search icon or presses a key combo). This is because most users will not benefit from a new search box (most will only have a few tiles), but some users with many kernel tiles (or even the "recently used file tiles" if we decide to include those) will.

• Need ability to Search for environments in the kernel selection

This can be implemented in jupyterlab-nebari-mode extension by replacing (extending) the default provider of ISessionContextDialogsinterface (replacing @jupyterlab/apputils-extension:sessionDialogs plugin). It has full access to kernel specs, so any kernel-specific metadata that we might want to display (and search in) can be passed via kernel spec.

A basic search function could be contributed to the JupyterLab core by rewriting the default selection dialog. However, some advanced users are strongly opinionated on the existing sections in the kernel selection list so it would be easier to contribute back an improvement which does not change that too much.

For reference, this is the existing kernel selection dialog:

• There will be "recent" notebooks available on the left sidebar coming native to jlab officially in 3-4 months but we could use this functionality in an extension that already exists.

For reference this refers to PR jupyterlab/jupyterlab#15483

• We can create a workspace which customizes layout. it saves as a json. We can push this to users so every launch will be the same. Will be in the 4.2 release.

For reference, this refers to PR jupyterlab/jupyterlab#15946

On the launcher itself, there are two upstream tickets in JupyterLab already:

• Improve user experience in Launcher jupyterlab/jupyterlab#3795 exploring redesign options
• Update the launcher UI to be extendable and modular jupyterlab/jupyterlab#12190 proposing to make the launcher more modular/ customisable

On the last point, it is worth considering if we should allow users to just drag widgets around the launcher to customize the layout it to their liking, especially if we are adding more optional things.

[dharhas]

random thoughts.

One confusion I have seen in new users is that they expect the launcher to be a file-browser when they see lots of Jupyter icons (one for each python enviornment) they mistake it for a list of their Jupyter notebooks.

The two things I use the most in the launcher is

• launch a new jupyter notebook
• launch a terminal

Things I have never used:

• new text/markdown/python file (I use nano/emacs from terminal or codeserver for these). But I can see why these should potentially stay
• Show Contextual Help (I actually don't know what this does)
• "Consoles" (I did an informal poll at one point, most folks don't know what consoles are and when demoed find the functionality odd)

We have had a client who customized the launcher to include shortcuts to favorites or example folders.

Specifically for Jupyter I feel like we need a two step launcher -> 1. Select Jupyter, 2. Choose environment
It would be nice to also do this for Terminal as well but this might not make as much sense -> 1. Select Terminal 2. Choose environment

[isabela-pf]

I’m following up upon request to bring you some very first passes at how the launcher could be adjusted to address the pain points listed above. These are not visually styled to match JupyterLab’s launcher at this point, only to make sure we are in agreement about the information the launcher needs, how that information should be oriented, and how the launcher should behave. Feedback on those aspects would be most helpful at this point!
Designs will also prioritize aligning with base JupyterLab’s launcher over being designed exclusively for conda-store-ui.

All directions replace the launcher’s cards with table-style lists. All directions also include a Search bar at the top that allows launcher contents to be filtered by text.

Option 1-1

Combines the Notebook and Console sections into one table and allows users to go kernel by kernel when selecting what they want to open. The Other sections become buttons to the side (or below, on narrower screens) to open new file types not related to kernels.

Option 1-2

Preserves the sections (Notebook, Console, and Other) already in the launcher, but replaces the cards with tables. Like the file browser, the whole row is a button to open the relevant session with a given kernel. The sections are now collapsible.

Option 1-3

Combines all launcher items into one table. The table is filterable by the search bar and by checkboxes to change what populates the table. While filtering came up when I was onboarding to this project, I was not clear what filtering would be most useful for this context; these are just example ideas that could be replaced.

Next steps

Feedback I’ve gotten in meetings means I’m going to move forward with the main concept of Option 1-2 for now, though other feedback on this issue is welcome and may change the way I take that next step. Thank you!

[isabela-pf]

I have another update! Moving forward with feedback from option 1-2, I’ve changed the following.

• Added a “starred” section that the user can populate with options from any of the other categories so they are quick to find.
• Labeled the icon category as Kernel to clarify the purpose of the icons.
• Added the caret icon to the columns of the table to mimic sorting like the File Browser does.
• Added a column to “star” options in each of the other categories.
• Added a scroll bar/limited height to each of the sections so that scrolling on the whole launcher is limited and users only have to interact in-depth with the section they want.

In action, that looks like the following.

Option 2-1 for JupyterLab

As a one-column list (for narrow screens or all if we choose it).

As a two column list.

Option 2-1 for conda-store-ui

We haven’t identified too much that we want to add uniquely to the conda-store-ui use of the launcher, but to demonstrate how other metadata can be added to this UI I’ve added a namespace option to the following mockups.

As a one-column list (for narrow screens or all if we choose it).

As a two column list.

[isabela-pf]

Feedback on the last round of mockups pointed out that problems with the current card-based launcher approach are not only to handle large numbers of kernels and/or environments and/or namespaces in a way that helps the user better find the one they want, but also to help with “decision clutter” too. These new designs cover a kind of branching need of “I just want to open something so I can get to work with the fewest clicks possible” and “I know exactly what I want to open with the fewest clicks possible.”

Changes are as follows:

• Added a title to the launcher to clarify what the launcher does (and that it’s not the file browser)
• Added the current directory for users to orient where they are and where they may be adding new files or starting new work.
• Changed section levels to be split by starting without a kernel and starting with a chosen kernel. These are still collapsible. Things originally in “Other” have been moved to
• Sections in Open New By Type are cards again! They are smaller cards with shorter text, but back to being cards for easy spotting.
• Favorites have been added to Open New By Type because they can be any category with or without kernels.
• Sections in Open New By Kernel are still tables. Rather than each being their own section, they are grouped with subheadings for Notebooks and Consoles.

Option 3-1

Keeps everything from the previous options, but reorganizes it as mentioned above.

Option 3-2

Option 3-1 with Starred removed.

Option 3-3

Option 3-1 with Starred removed and no cards.

I will keep updating, next time with kernel selection updates as well. Thanks for reading and giving feedback!

[krassowski]

Some very early work on the implementation side, in case if this helps with final design iteration(s):

[isabela-pf]

I'm following up with a summary of the feedback the last round of mockups received for record-keeping purposes. Let me know if you have any questions!

• Move search to Open New By Kernel section because that is where search is most needed. Make the empty field text be "Search for Kernel."
• Add a title to the launcher (other than the tab name title). Maybe "Launch New…"
• Label the file path as "Current directory"
• Change VSCode icon to match Code Server
• Add Python File to Open New By Type cards (@krassowski already did this above!)
• Move Contextual Help to the top of page/in its own section since it's more a global setting than a new file.

[kcpevey]

We are going to pause here on design iterations and work on implementation. Once we get a POC in place and have some user experience to work with, we may revisit design. Thanks @isabela-pf for the great work!

[krassowski]

Regarding the kernel selector there is also some designs in jupyterlab/jupyterlab#14717 but I don't think they get us closer to what we want to achieve.

[krassowski]

A brief update for anyone following:

• favouriting was implemented
• persisting favourites and last used is implemented
• additional columns based on kernelspec are implemented, allowing to display conda environment data or debugger support
• hiding and moving columns is implemented (not everyone cares about the debugger)
• "Current Directory" prefix was added
• kernel selection dialog is partially implemented

Kernel selection dialog is partially implemented:

• it shows the table with kernels based on kernelspec
• the additional information (preferred kernel) is shown
• the running kernels are shown

Not sure whether to go for

• (a) clicking on a row checks a checkbox (and then you press Select), or
• (b) clicking on a row starts the kernel

One blocker on using more metadata from conda is the PR to conda-nb-kernels being stuck.

[krassowski]

One more snapshot:

[dharhas]

Should we move this issue over to the implementation repo - https://github.com/nebari-dev/jupyterlab-new-launcher/

[kcpevey]

Probably but since they are in different orgs, we can't do a "transfer". We'd just have to create a new issue and copy the relevant info.

[kcpevey]

Not sure whether to go for
(a) clicking on a row checks a checkbox (and then you press Select), or
(b) clicking on a row starts the kernel

I'd prefer fewer clicks when possible so I'd pick (b)

One blocker on using more metadata from conda is the PR to conda-nb-kernels being stuck.

Can you link to that work for reference?

Also, for the kernel selector, I think we talked about getting info from the metadata which would allow us to add some organizational UI niceties if they are available (e.g. namespaces in nebari or whatever other grouping people would like to use). Is that affected by the blocked work you mentioned?

Design for the conda env selection on jhub apps for reference:

[krassowski]

(a) clicking on a row checks a checkbox (and then you press Select), or
(b) clicking on a row starts the kernel

I'd prefer fewer clicks when possible so I'd pick (b)

Yes, it's tempting to go this way as it is also less work but then we need to rethink the "Always start the preferred button" checkbox and buttons.

Can you link to that work for reference?

Yes, it was merged today: anaconda/nb_conda_kernels#262

Also, for the kernel selector, I think we talked about getting info from the metadata which would allow us to add some organizational UI niceties if they are available (e.g. namespaces in nebari or whatever other grouping people would like to use). Is that affected by the blocked work you mentioned?

The namespace will be available as a column. I guess you are suggesting having a filter by environment above the table, or in context menu over column?

[kcpevey]

The namespace will be available as a column. I guess you are suggesting having a filter by environment above the table, or in context menu over column?

I was responding to your "Select Kernel" UI. I wasn't aware that would be part of this work, but if it is, I thought I'd share the designs we had for that. If the namespace will be available as a column there as well, that will work too.

[krassowski]

I wasn't aware that would be part of this work, but if it is,

@dharhas can you confirm if this is part of it or not?

[dharhas]

Yes, we need this component as well.

[krassowski]

Should we move this issue over to the implementation repo - https://github.com/nebari-dev/jupyterlab-new-launcher/

I think this is a good time to evaluate the initial implementation (you can try it on binder: https://mybinder.org/v2/gh/nebari-dev/jupyterlab-new-launcher/main?urlpath=lab), start opening individual issues over on https://github.com/nebari-dev/jupyterlab-new-launcher and maybe close this issue.

The next step for me is to investigate improvements specific to conda-store (which columns to show, whether to split some metadata into multiple columns, think about filtering by environment etc) and implement changes based on feedback.

[kcpevey]

I agree! Great work!

[kcpevey]

Moving discussion over to nebari-dev/jupyterlab-new-launcher#4 and closing this one!