Create a workspaces GUI

[RafalSkolasinski]

trafficstars

Jupyterlab's documentation only explain how to manage workspaces via URLs and CLI.

Are there any plans to provide some GUI for those? At least create new one and list / choose / delete existing ones?

[afshin]

Hi @RafalSkolasinski. We want a workspaces GUI of some sort in JupyterLab. And your suggestion of just a list to begin with is similar to conversations we've had about where to start.

I'd be happy to mentor anyone who wants to work on this feature. I've labeled the issue as help wanted.

[ibdafna]

I'm keen to chip in. Where do we start?

[afshin]

@ibdafna Great!

I would start by making a feature branch in your fork and creating a workspaceui-extension as a new extension that you model off of running-extension and workspaceui modeled off of running.

CC: @tgeorgeux @ellisonbg if you know (or are) someone who would like to work on the user experience of this UI, let's connect them with Itay. For now, I think a list of sessions is the right place to start.

[Madhu94]

@ibdafna Did you get started on this ? I was wondering if I could pick it up.

[RafalSkolasinski]

Is anyone working on this right now?

[ibdafna]

Firstly - apologies for not noticing the comments earlier. I started working on this, progress not as quick as I would have wanted. @Madhu94 happy for any help on this! Give me a couple of weeks and I'll post a WIP PR.

[tzuni]

Also interested in chipping in on this or at least watching eagerly from the sidelines!

[Madhu94]

@ibdafna Sorry, I missed the replies to my question. Still interested in picking this up if you haven't or helping to push this along if you have.

[Madhu94]

As an update, in case anyone's interested, I've also started working on a workspaces extension in userland. I'm facing minor blocks(like #7785). I'll update once I'm done.

[afshin]

@Madhu94, awesome! I'm glad you are taking this up!

[allefeld]

quoting myself from #7876 "interface to manage workspaces":

Under the URL /lab/workspaces without an appended workspace name, an interface to manage workspaces should be shown. that is:

• a list of existing workspaces, click opens it
• for each existing workspace, options to delete, rename, clone
• option to create a new workspace, either empty or as a clone of the default workspace.

[afshin]

@allefeld I would say a good way to start is to just add a command to the command palette and probably a menu item but not to tie it to a specific URL yet. URLs are a place in a user interface we should be very conservative about because they are one of the last things that change and they can be very long-lasting.

Since this is a user interface for managing workspaces, simply launching it the way we'd launch any other extension (i.e. from the command palette or menu or launcher) seems like the right way to invoke it. I'm not 100% opposed to the URL being used this way, but it's not where I would begin.

[allefeld]

@afshin, I thought it would be the logical way to do it, but I understand.

[isabela-pf]

FYI, I'm starting to work on a potential experience and UI for this. I'll post mockups as I make progress.

Between the helpful comment from @allefeld and JupyterLab docs, I think I have a good idea of what functionality and use cases are needed, but more input in that area is always useful since I've rarely used workspaces myself.

[isabela-pf]

I’ve been making my way through each of the interactions needed for this feature and it’s turning into a lot to post together, so I’m going to break it up. This comment will be about the potential placement of a workspace UI in either the sidebar or the launcher.

Since it was recommended in the sidebar on this thread, I’ll start there. I don’t think workspace management makes sense in the command palette since the command palette schema is more of a collection of actions and things you can do while workspaces are really just the set up of a Lab experience. I put it in the Open Tabs section for now because workspaces will change what tabs are open, but I am worried it might be easily missed here.

I think the best option for placement of a workspace management UI is actually in the launcher. Since workspaces change the URL, open files, and arrangement of tabs, the launcher seems like the place I’d expect such a large visual change to happen.

As it is currently, I think the launcher needs some work (which I’m working on in the background based on multiple issues), but this design would match with current launcher expectations.

Right now I’m tentatively using this modified version of Material Design’s dashboard icon to represent workspaces. I’ve given it only a little thought, so if anyone has feedback on it feel free to share. If anyone wants to use it, let me know and I'll get you an SVG since GitHub doesn't support them in comments.

[blink1073]

Hi @isabela-pf, thanks for digging in to this! I have two concerns:

• The number of workspaces can get large (we create auto-workspaces when we detect another browser tab with the same url)
• We need to be able to delete workspaces

[allefeld]

I think the best option for placement of a workspace management UI is actually in the launcher. Since workspaces change the URL, open files, and arrangement of tabs, the launcher seems like the place I’d expect such a large visual change to happen.

@isabela-pf I understand your reasoning, but I'm not sure I agree. Everything else in the launcher adds something to the current workspace, so having items there change the entire workspace would be surprising.

I'm not sure what I would recommend instead, but one option would be a modal dialogue. A large box that covers most but not all of the viewport, and with the current workspace in the background dimmed or blurred.

What would creating / selecting a workspace do? Replace the one in the current tab, or create a new tab?

[jasongrout]

Everything else in the launcher adds something to the current workspace

To be more precise, everything in the launcher replaces that same launcher tab with exactly one activity.

so having items there change the entire workspace would be surprising.

I agree.

[isabela-pf]

Thanks for the great feedback! I’ll have to think more about where a workspace UI fits. For now I have mockups of some of the other interactions that are not influenced by that UI placement choices. I think these interactions make sense as dialogs regardless of UI placement, though that could change in the right context.

To create a new workspace, it seems to me like all that is needed is the workspace name. This dialog makes it so that setting up a workspace stays quick, but is more explicit about workspaces generating URLs. I still have filler brackets in this mockup because I haven’t looked into what invalid characters there might be for a workspace name. Creating a new workspace this way would create a workspace based on what the user has open, just as workspaces do now.

This error in the existing dialog design can also be used for other workspace naming errors (like in renaming a workspace).

One of the key things I think this UI will need is a context menu with these items ordered first to last:, rename workspace, clone workspace, export workspace, reset workspace, and delete workspace.

I haven’t made the rename workspace flow yet because I had some questions about how that would work. I’ve grouped all these questions in the comment below.

Cloning a workspace should look a lot like creating a new workspace because a cloned workspace is still a new workspace. The only changes here are in the text. Cloned workspaces have default suggested name of [existingworkspace]clone (numbered as necessary), but leave the text highlighted so it can easily be named before it is actually cloned.

Deleting a workspace seems like it might have an extra confirmation so that users don’t do it by accident. I have a confirm deletion dialog here, but I want to know the frequency of deletion and/or how irritating it is to delete a workspace by accident to make that choice. This is the same for resetting workspaces.

Let me know if this was helpful for starting to get a feel for how these features might need to interact with a user.

[isabela-pf]

I found myself having a couple of questions I haven’t been able to find answers to myself, so I’m listing them here.

1. Can you currently rename a workspace? I’m not finding it in the docs. If you currently can, what does renaming a workspace do to the URL? Does it create a new URL accordingly? If it creates a new one, is the old one still there or auto-deleted?

2. I have a few questions about what is needed to import a workspace. It looks like importing is mostly about pointing JupyterLab at the appropriate JSON file, so could this be done with the browser’s default file browsing interface? It also looks like it pulls the workspace name and creates the URL from that file name by default, so I don’t think this needs its own unique interactions other than an error dialog notifying of a failed import (like this).

3. What kinds of warnings might happen when opening a workspace? I haven’t triggered anything except for having a dialog that warns me I have the same file open in multiple workspaces. Are there any other errors that should be accounted for like lost file paths?

4. Is it common to delete and reset workspaces? Is is a big loss if done by accident? The frequency and severity of consequence will help decide if confirmation dialogs for both is going to be necessary or an annoying extra click.

[blink1073]

Here are the operations we support from the browser client: https://github.com/jupyterlab/jupyterlab/blob/e7317f21b48183423e375dc266476a4289eb0fa3/packages/services/src/workspace/index.ts#L42.

There are also options from the command line:

$ jupyter lab workspace --help
Import or export a JupyterLab workspace

There are two sub-commands for export or import of workspaces. This app
    should not otherwise do any work.

Subcommands
-----------

Subcommands are launched as `jupyter cmd [args]`. For information on using
subcommand 'cmd', do: `jupyter cmd -h`.

export
import
...

1. The URL reflects the name of the JSON file on disk. You can find the location from the command line:

$ jupyter lab paths
Application directory:   /Users/stslve/miniconda/share/jupyter/lab
User Settings directory: /Users/stslve/.jupyter/lab/user-settings
Workspaces directory: /Users/stslve/.jupyter/lab/workspaces

2. The file locations in the file browser are scoped by the --NotebookApp.notebook_dir argument to the server application.

3. We try to re-hydrate all items in the workspace. It is up to the re-hydration logic of each plugin what it does. For documents, if the document is not found on disk it fails silently and does not open any panel for that document.

4. Do don't have any method to delete a workspace (though it could be added to both the UI and the CLI). We support the ?reset URL query parameter to get a clean slate workspace. If you browse to a workspace and add the ?reset parameter then that workspace is cleared.

[isabela-pf]

I previously posted dialogs that would appear separately. I'm realizing that @allefeld 's last suggestion may have been more along the lines of a single dialog-like interface with all workspace actions navigable from there. Depending on where a workspace manager is placed in the UI, this might be a preferable approach. Something like this:

I still think that deleting, renaming, and resetting a workspace should be done from a context menu when viewing all existing workspaces.

[blink1073]

I like it! I agree that deleting, renaming, and resetting should be context-menu operations. I have a strong preference not to make it a modal dialog though, but a main area widget.

[tgeorgeux]

I agree that this should be a main area widget, not a modal.

[isabela-pf]

I agree that a modal doesn’t seem to me like it’s the best experience to support workspace management.

I know I’ve proposed different possible placements for this so far and they’ve all seem to have had critical issues that conflict with either what is needed from a workspace manager or the schema for that area of JupyterLab. So I don’t keep providing mockups with those types of issues, I think it might be helpful for me to list out where I’ve considered possible places for a workspace manager and the potential pros and cons. Please point out if I’m missing any placement possibilities or misunderstanding the concerns for each.

As short as I can make it, here’s the options I’m seeing:

Menu bar

• Pros: Might be the least jarring experience for the degree of change switching workspaces creates since it already holds commands of a range of levels (meaning it already controls things that would change JupyterLab UI significantly).
• Cons: It’s an inflexible UI to work with if all of the workspace manager is meant to fit there. It would make more sense to have something that opens from the menu bar than actually manage workspaces through a mess of branching menus.

Side bar

• Pros: Relatively flexible UI means there is opportunity to make a workspace manager that serves user’s needs more than trying to fit those commands in a UI not meant to hold anything like that. Relatively flexible amount of room since side bars can scroll to accommodate large workspace numbers.
• Cons: Users might not expect as big of a change as switching workspaces to be initiated from the side bars since this area holds mostly commands that influence documents and their parts over the whole JupyterLab space.

Tool bar

• Pros: I can’t think of any pros. I’m only listing this to accurately cover available areas in JupyterLab.
• Cons: It makes no sense to put a workspace manager in an area that holds only document-level commands.

Modal

• Pros: Relatively flexible UI. Modals are major workflow interruptions, so it might help indicate the degree of change initiated when a user switches workspaces.
• Cons: Modals are major workflow interruptions and should not be overused. They are more ideal for information and warnings that the user absolutely needs to know and address immediately.

Launcher

• Pros: I think of the launcher as a place to get started that highlights the range of options users can access. Conceptually, I think a workspace manager fits this. It also has somewhat flexible UI.
• Cons: Current launcher behavior (and user expectations of it) clashes with the degree of change that some actions in a workspace manager might cause. I mean things like current launchers opening the selected option and replacing a single launcher tab, not the whole set of tabs and tab orientation like a workspace.

[isabela-pf]

I talked out ideas with @tgeorgeux and we agreed it was worth trying an approach that allows for workspaces changes outside of the full workspace manager or typing the URL combined with the full workspace manager I’ve been working with so far. The full workspace manager can be accessed from a button right next to it. I want to tweak the UI a little more in this area, but this is the basic idea of how it would work (searchable drop down list) and where it could go.

As has been mentioned before, there’s not really an equivalent level of change to the page reload caused by changing workspaces, so it doesn’t quite fit grouped with other major areas of the UI. This approach puts it in the menu bar since this area holds other larger changes that can clearly affect more than documents as workspaces do.

The workspace manager in full has a lot in common with the last iteration, but is now in a main area widget as recommended. I added search bars to help navigate potentially large numbers of workspaces (as mentioned by @blink1073 ), but I’d like feedback if that approach makes sense to people.

If I get positive feedback to keep iterating on this approach, I’ll start designing the bit by bit interactions in this process to get a more comprehensive picture of a potential workflow.

As a side note, I am curious what people think about list UI similar to the kind of proposals for the launcher here. I’ve been working with card UI to match existing JupyterLab conventions, but they do take up a lot of space. It seems especially unhelpful when a focused area like this is only going to show one type of content (workspaces) versus the variety launcher might have. This could be a chance to explore lists without interrupting users’ launcher workflows.

[blink1073]

I love this version! We may also want to filter out the auto-generated workspaces by default as well. I also like the ability to toggle between launcher view types and a "memory" of what you last used.

[ellisonbg]

One important point - we have been talking about possibly changing how workspaces work in the improved single document mode. I think a workspaces UI will still be relevant, but some of the ideas may change. Plan on working on this over the weekend and will give more details.

On Fri, Jun 26, 2020 at 4:57 AM Steven Silvester [email protected] wrote:

I love this version! We may also want to filter out the auto-generated workspaces by default as well. I also like the ability to toggle between launcher view types and a "memory" of what you last used.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyterlab/jupyterlab/issues/6944#issuecomment-650140515, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAGXUE3J4HBYIQ5AWJRZHTRYSELBANCNFSM4IJFBC2Q .

-- Brian E. Granger

Principal Technical Program Manager, AWS AI Platform ([email protected]) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[afshin]

Related to this work but independent of it, one concept that has come up a few times -- which I think we should build -- is a file handler for workspace files so users can double click them in the file browser and load/save them from outside of the workspaces manager as well as from within it.

[ellisonbg]

I like that idea a lot - in that model does the usual file browser become the workspace UI?

Sent from my iPhone

On Jun 26, 2020, at 9:00 AM, Afshin Taylor Darian [email protected] wrote:

 Related to this work but independent of it, one concept that has come up a few times -- which I think we should build -- is a file handler for workspace files so users can double click them in the file browser and load/save them from outside of the workspaces manager as well as from within it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.