Explore ux for switching notebook kernels/connections

[miguelsolorio]

This issue is to capture the ux explorations for switching notebooks kernels/connections. These examples should consider connecting to a local server as well as a remote one. You can think of the relationship as servers (jupyter server) + databases (kernels).

Option A

This option shows local kernels by default and then provides an option to add a server. Once an additional server has been added, when the user attempts to switch kernels we'll show the parent (server) list first and then drill down to the kernels. If there is authentication (like in the Azure ML extension) then we'll use the authenticator provider.

Option B

This option also shows local kernels by default, but utilizes a custom view for managing connections. The user can switch kernels either from the quick pick or the view. Any kernel that the user connects to gets added to the respective list (similar to opening Recents quick pick).

[greazer]

So does option A basically require two clicks to change a kernel no matter what?

IMHO, Option B seems to be a good marriage of existing expectations for changing kernels while providing a really smooth way to introduce the selection of other servers in the mix.

[miguelsolorio]

@greazer for option A, it is an extra click after you add an additional server. If there are no servers then you always get the kernel list. We could update this so that you always land on the list of kernels with an action at the bottom to "Change servers" and have the "Add server" on the server quick pick.

I also agree that Option B feels like a smoother experience. Do you have any thoughts about using a custom view to manage kernels?

[greazer]

@misolori, not sure what you mean by "custom view" in this context. Something different than you described in option b?

[jilljac]

I like option B a lot, for two reasons.

1. It's a smoother and more visible experience. We've seen in the past that discoverability of status bar actions is a problem, especially for new users. We've also heard from partner teams like AML and ADS that managing connections is one of the highest priority pieces of information that they want to expose to users.
2. There is more opportunity for flexibility. There could be cases where users need to manage "one-to-many" connections for compute and/or data, and this provides hierarchy with the potential for flexibility. - Question on this: Would the panel show the connections for all open notebook tabs, or just the active tab/document? It might be interesting to explore scenarios for both and see which is more suitable.

[miguelsolorio]

@greazer in the gif I show a view in the sidebar where you manage your kernels:

Which is linked to via the quick pick at the bottom (the "configure connections):

[miguelsolorio]

Would the panel show the connections for all open notebook tabs, or just the active tab/document? It might be interesting to explore scenarios for both and see which is more suitable.

@jilljac I think this would be on a workspace level and then the "active" kernel would depend on the active file. We do this currently where whatever file is active, see below where the "outline" and "timeline" views change based on the active file:

[SiddhanthUnnithan]

Apologies for not being able to make it to the meeting. I'm in agreement with @jilljac - Option B is much smoother. The more we can avoid users having to click around components of the UI to initiate flows, the better. We were in conversation with a 1P customer earlier today who mentioned wanting to switch seamlessly between remote kernels (on different servers). The hierarchical layout in Option B makes it a lot easier for customers to see the list of kernels they've connected to across all the hosts in their workspace, with a single-click on the kernel level to initiate the connection.

[rchiodo]

+1 for option B.

[jilljac]

Suggestions for Option B:

1. Contextual section - It would be great to have a section that shows all the active connections for the focused notebook. This could be particularly valuable in multiconnect scenarios where the status bar may not be ideal for showing more information. For simple 1:1 use cases, showing the server/environment and the kernel is sufficient, but there may be additional connections like databases, multiple kernels, or parameterized workflows that might be relevant to show. This section could also show status of kernels and connections - as demonstrated as a green "check"

2. Show an "all connections" list - this would be essentially an MRU for connections you have used in the past (could also be filtered to sort alphabetically, etc). It would show servers, kernels, databases, etc but it wouldn't live update or show status. This would allow 1-click access to previous connections, or invoke the multistep quickpick if you want to choose from a full list of kernels available on a server (like what Miguel proposed above).

I would be interested to have more understanding of the multiconnect scenarios that .Net might be addressing, because there is still some unresolved complexity with managing multiple connections. There may also be additional actions to show in this view that would be helpful to customers.

[IanMatthewHuff]

I like option B as well. The one thing that does throw me a tiny bit is the "Configure Connections" at the bottom of the kernel picking list. Is that just to provide an entry / discovery point for the connections pane on the side bar? Say I was a user just working with local host, I'm not sure if I would know what "configure connections" would mean in the context of my kernel picking control. Given that the watermark text says "Select a kernel to connect to," I might assume that it's managing the local kernels that I can connect to. Or, even if I did want to connect to a remote server, I'm not sure that I would know that "Configure Connections" in the kernel picker would be my entry point (assuming that the connections pane I was not already familiar with).

Just a personal opinion here, but I feel like the naming clarity would be better to explicitly call out that this is a remote or server connection. Clicking it could do the exact same action as you were showing to open the connections pane. But worded like so:

Pick A Kernel:

• Kernel A
• Kernel B
• Kernel on remote server (remote connection?)

For a local only user I'm not going to click this on accident now as it's explicit that this is picking a kernel on a remote machine, not configuring options for how I connect to my local kernels. For a user who wants to connect to a remote server it's a more explicit entry point as "connection" can be a bit vague. And it since this entry point is in the kernel picker it makes it clear that we are connecting to run a kernel on the remote machine / connection, so it doesn't seem like a non sequitur to have random configuration options links showing up in the UI to select a kernel.

[miguelsolorio]

Thanks everyone for the feedback! I do agree that the terminology can be improved, it's not final at all so happy to hear suggestions. It sounds like there is interest in having a view that shows all current connections for the active notebook, similar to our open editors view + additional metadata (database connections), like @jilljac's mockup above. I also think that adding an entry point to add a new connection from the kernel picker makes sense as well:

It's an interesting point about whether we want to use "connection" vs "kernels" vs "remote server" because you can add both a remote and local server so remote doesn't feel appropriate here? I think that's why we went with a general "connection" name to cover all bases, but I wonder if there are better words to use here. Happy to hear suggestions.

[miguelsolorio]

Since the design explorations have concluded for this item I will be closing this issue. Engineering will create a new issue when implementation starts.