UX/UI proposals for Gator

[isabela-pf]

Hi there! I’m part of a team looking to integrate conda-store into gator (thanks to @fcollonval for meeting with us). I would like to start this issue as a place to propose some UX and UI changes to make gator more user-friendly no matter what environment management is being used.

I also have very little experience with designing for environments, so I know there’s a lot of things I don’t know in this area. Feel free to let me know if you think something I’ve proposed doesn’t actually make sense or if I’m missing an important feature.

Some goals

• Show the primary information in the sidebar while still expanding to the main document area if desired
• Organize info in a familiar way (since environments are unfamiliar to many users)
• Organize info in a way that can be applied to different environment management systems with different features

If you have thoughts on other goals to keep in mind, let me know.

Proposal

This is still pretty rough (and mostly without color), but I’d rather share ideas and get feedback early!

So far, I’ve been working on the main organization of content and not the more specific interactions (like no mockups for install new package yet). Once we are okay with an idea for organizing info, I plan to jump into those features.

One of the problems I heard about early on was trying to convey a lot of info in not a lot of space while being clear the relationship between the layers (like which packages are in which environment). In many ways, this is similar to what the file browser does. So this proposal extends that behavior.

It also makes it so that much of the information fits in the sidebar and users don’t have to use the main document area unless they want to.

The basic list of environments in the sidebar:

An environment with expanded information in the main document area:

And context menus show the same basic interactions as in the top of the sidebar. (Though I'm not sure what else should go here.)

This is also the same structure for packages within an environment.

Try it out

I think the interactions can be most easily seen in this simple prototype. ✨

Problems

• In the file browser, a folder icon tells users that they can click into in while file format icons designate a kind of end-of-the-line. We may need some equivalent visual to help inform users how to interact with the different types.
• I worry about having users be able to go all the way back to the environment manager in the kind-of file path, but I’ve gotten feedback it’s important to know. I’m not sure if there’s a better way to communicate it since I’d suspect most users are concerned with listing environments and packages only.

Thanks in advance for the feedback!

[SylvainCorlay]

Hey @isabela-pf this is great to see you here. Thanks for putting together these mockups.

We have also bee working on some UX designs for an environment editor and manager, and thinking about this kind of interactions lately. (Pardon the use of French in the UI mockups).

Auto-complete on adding dependencies: (Collapsed diagnostic pager)

Expanded diagnostic pager when specs are not solvable

Expanded diagnostic pager with resulting set of packages

Pure file editor interface for modifying the same environment - with auto-complete on schema, package and versions

Said auto-complete UI has been developed in #141.

[fcollonval]

Thanks @isabela-pf to open up the discussion.

Some goals

* Show the primary information in the sidebar while still expanding to the main document area if desired
* Organize info in a familiar way (since environments are unfamiliar to many users)
* Organize info in a way that can be applied to different environment management systems with different features

If you have thoughts on other goals to keep in mind, let me know.

Some secondary goals of the current extension are:

• Discover which packages have update available
• Determine the source (aka channel) of a package
• Discover why a specific package is installed in my environment (this one is a bit hidden see the PR demo)

Other feature (not implemented) that has been discussed:

• What is the license of a package? Are some packages under a forbidden license in my company?

This may be useful to know if we need to add more columns for example in the listing.

Proposal

It also makes it so that much of the information fits in the sidebar and users don’t have to use the main document area unless they want to.

❤️

The basic list of environments in the sidebar:

One point I'm worried about is the breadcrumbs. In the classical case (not conda-store), environments are stored on the user PC in multiple places. Would it be clear for the user that the breadcrumbs is not showing the real computer folder structure but an abstraction of it?

What is the objective of the link button in the toolbar?
Do we need a edit button in the toolbar?

An environment with expanded information in the main document area:

We gonna need to iterate a bit on the information to be displayed here (probably this will depend on the environment management system). Does that panel needs an editable mode?

And context menus show the same basic interactions as in the top of the sidebar. (Though I'm not sure what else should go here.)

For the standard management system, a Clone environment will useful and the Create a file in this environment won't make much sense.
Do we need something like Open (but I don't like that verb in this case) to open the environment packages list?
Do we need something like Edit or the edition should be done from the details panel?

This is also the same structure for packages within an environment.

We may want to have additional information (may be optional columns) for the channel and maybe the license. We definitely need a way to list quickly the packages that can be updated (as the packages list will most likely be too long to see all of them in the sidebar).

---

How do you image the UI for creating/editing the environments? Would you rather use a main widget similar to what Sylvain posted or a in-sidebar form?
I'm curious also to see on your proposal for the installation panel.

Try it out

Thanks for sharing the mock-up

Problems

• In the file browser, a folder icon tells users that they can click into in while file format icons designate a kind of end-of-the-line. We may need some equivalent visual to help inform users how to interact with the different types.

Definitely displaying an icon for the environment like the box you use sound a good indicator. For the packages, I don't if this is needed.

• I worry about having users be able to go all the way back to the environment manager in the kind-of file path, but I’ve gotten feedback it’s important to know. I’m not sure if there’s a better way to communicate it since I’d suspect most users are concerned with listing environments and packages only.

That's a good question actually and the input of @pierrotsmnrd will be interesting. Do you imagine the extension to use simultaneously multiple managers or they will be exclusive?

[pierrotsmnrd]

Hi everyone :)

Thanks for the feedback on the mockups @fcollonval, it's very valuable !
I'll just answer the last question for the moment :

Using multiple env management systems at the same time would bring paradoxes and confusion :

• You cannot manage a single environment with multiple environment managers
• It will be confusing about why some environments have some features and others don't, while they are all next to each other.

also, the use cases for conda/mamba on one hand, and conda-store on the other hand, are kind of mutually exclusive : Users using conda/mamba won't need to use conda-store, and the other way around.

Conclusion : The extension should use env managers in a exclusive manner. The users will be able to switch from one environment management to another.

For the other points in your feedback : we're processing them and thinking them through.

Also, interesting UI and feature ideas @SylvainCorlay ! I like the idea of the diagnostic pager when an env is not solvable.
Do you have other mockups, designs and/or ideas to share, so we can take them into account ?

Have a nice day you all :)

[fcollonval]

Conclusion : The extension should use env managers in a exclusive manner.

Great this aligns with my vision 😉

The users will be able to switch from one environment management to another.

For this one, you mean that the user should be able to switch without restarting JLab?
Related to that @isabela-pf what about using the icon left of the breadcrumbs to change depending on the kind of manager. Then the path in the breadcrumbs will inform on the environment only and the action to change the environment manager will be available by interacting with the root icon?

[dharhas]

I like the idea of exposing the licenses for each package. I needed to check this yesterday.

[isabela-pf]

Sorry for the delayed reply; my time is split between a lot of projects right now.

@fcollonval thanks for the line-by-line feedback. I really appreciate the additional goals so I know we are at least kind of on the same page.

The idea about using icons by environment manager in the breadcrumbs is a great idea. I’ll make sure to get them added in on the next round of mockups.

One point I'm worried about is the breadcrumbs. In the classical case (not conda-store), environments are stored on the user PC in multiple places. Would it be clear for the user that the breadcrumbs is not showing the real computer folder structure but an abstraction of it?

I am a little worried about that too. I was hoping that since nothing is referenced as a file that it would help. I'm totally open to ideas that makes this more clear.

What is the objective of the link button in the toolbar?

I was using it as an expand into the main document area case, but this is good feedback. If it’s not clear, then I should probably be using something else.

Do we need a edit button in the toolbar?

Probably! Thanks for catching that.

We gonna need to iterate a bit on the information to be displayed here (probably this will depend on the environment management system). Does that panel needs an editable mode?

I agree, this is the least worked out area to me. Does it make sense to have an editable mode overall, or by section. I’m asking because I imagine there will be non-editable information, such as a license.

On another note, I don’t see any conflicts in the work @SylvainCorlay shared, either. I think having that quick and abbreviated list view in the side bar is one of the first things I’d like to see added, while the main document area stays more open as a space to make larger changes like what was shown above. I look forward to seeing the features in gator in the future because they sound super helpful!

---

My next goal is update mockups based on this feedback and include more interactions like listed above (editing, installing and uninstalling, so on).

[fcollonval]

Thanks @isabela-pf

I'll wait for the new mock-ups. It helps a lot to discuss with those supports.

---

breadcrumbs

I am a little worried about that too. I was hoping that since nothing is referenced as a file that it would help. I'm totally open to ideas that makes this more clear.

I don't a better idea - so let's try like that.

the link button in the toolbar?

I was using it as an expand into the main document area case, but this is good feedback. If it’s not clear, then I should probably be using something else.

For the other side panel of JupyterLab, the main widgets are usually opened from action on list items or context menus. So I think the patterns of using double-click, context menu,... would be enough to trigger the detail views.

[isabela-pf]

So I’ve been scrambling to get some ideas completed for a few different discussions happening above. I have a few goals here, so I’m going to break them into a few comments so I can get them to you faster.

First, here’s an updated version of the last set of mockups addressing @fcollonval’s feedback. I figured it’s easiest to compare that way.

Selected pieces from that prototype:

1. Changing the icons used for icon managers to make it clearer that they are distinct from environments.

2. Updated context menus for environments and packages, respectively.

3. Updated detailed views of environments and packages, respectively.

For reference, here’s my rough mockup changelog:

• “Open in main area” button removed
• Added “edit” button to main sidebar button area
• Added logos for environment management
• Remove transient “info/details” button
• Added more specific title to detail view
• Updated context menus based on feedback

One piece of feedback from @fcollonval that I didn’t follow was making the box icon in the path at the top of the sidebar match the environment manager in use. I tried it, but am hesitant to have a UI landmark like that change. It also relies on users recognizing the logos, and at a quite small size.I might be able to be convinced, otherwise, though.

I'm experimenting more with creating new environments and installing new packages (two seperate actions, but a similar experience in terms of the idea of adding something new). There are a lot of ways to potentially represent this, so I'm trying to write up a helpful description now.

[isabela-pf]

Here’s some proposed flows for adding items, specifically creating new environments and installing packages. Some notes:

• I’m showing this with conda-store because I know it better. I know there are some things (like specifications) that I’m not sure have equivalents in mamba, but I figure it’s easier to subtract from the elements here than add.
• I think that both experiences should share most if not all their behavior, so, for example, if we like the way one proposal works in the sidebar, then I think both options should fit in the sidebar.
• In many cases, I’m not sure if a faster means of adding new things or a more precise one is preferable (or both?). I’d love to hear feedback on that based on the below mockups.

Option 1

Sidebar
These versions replace the list with a UI focused on the minimum options.

New environment

This version creates a new environment based on where the user currently has navigated. Description and specification (to make an environment immediately ready to go) are optional.

Install package

Package installation seems to need even less information, so it fits nicely in the sidebar. Package name and version will similarly trigger the install of a package based on the environment the user has navigated to. The package version will default to the most recent one once a package is selected.

To be clear, I think that package name should kind of fuzzy-search for package names once users start typing. We don't want to rely on people remembering or accurately typing package names every time.

Option 2

The main area

These options take advantage of the larger space of the main area to have more detailed options on adding content.

New environment

This has a lot in common with its Option 1 equivalent. This time, users can create the new environment anywhere and have several options for creating a complete environment from other info (I know that these features don't exist yet; I wanted to show off the pros and cons of having more space regardless). It's split into Required and Optional for clarity since I think this option could be overwhelming. I also considered making this collapsible to hide Optional if users want (and so the Create button isn't as far down on the screen)

Install package

The biggest change for package installation I think this larger area works well for queuing up several packages at once. I don't know if this is useful at all, so feedback there would be helpful

Option 3

Sidebar

These options are the shortest path to adding content and behave like the file systems of similar IDEs.

New environment

Based on where the user has navigated, the add button creates a new entry in the list of environments and lets users name it. No other information is needed in this flow (I don't know if that's technically feasible though), and all other details (including any packages) would be configured via the edit button rather than upon creation.

Because I'm not sure if this is possible, I do have an idea for another way to handle this flow if more information than environment name is needed.

Install package

Just like environment creation, this installs a package in the place a user has navigated. As mentioned in prior versions, I still think this needs some kind of check for spelling/if the package exists as well as defaulting the version the the latest version of the chosen package.

---

Next up is removing environments and uninstalling packages. I'll be back with more info soon!

[fcollonval]

Thanks @isabela-pf for the updated design.

Selected pieces from that prototype:

1. Changing the icons used for icon managers to make it clearer that they are distinct from environments.

This looks nice 👍

2. Updated context menus for environments and packages, respectively.

One minor question on the context menu, should the create environment and install package be part of the context menu when the context menu is triggered from an item? In filebrowser, it is common to see the new action only on context menu on the empty white space.

I would bring the delete/uninstall action before the new action.

3. Updated detailed views of environments and packages, respectively.

I like them.

Minor comment, it will be nice to get a visual indicator that updates are available for an environment or a package.

One piece of feedback from @fcollonval that I didn’t follow was making the box icon in the path at the top of the sidebar match the environment manager in use. I tried it, but am hesitant to have a UI landmark like that change. It also relies on users recognizing the logos, and at a quite small size.I might be able to be convinced, otherwise, though.

I'm fine with the current proposition as the information is in the breadcrumb.

[fcollonval]

Here’s some proposed flows for adding items, specifically creating new environments and installing packages. Some notes:

* I think that both experiences should share most if not all their behavior, so, for example, if we like the way one proposal works in the sidebar, then I think both options should fit in the sidebar.

Indeed they will.

* In many cases, I’m not sure if a faster means of adding new things or a more precise one is preferable (or both?). I’d love to hear feedback on that based on the below mockups.

I like the side bar approach (option 1) better. The fast approach (option 3) is good for package but too simple for environment. The main area proposal (option 2) has some advantages in term of verbosity. But I find the namespace / environment selection a bit redundant with the side bar.

Regarding the ability of stacking multiple changes, it usually happen when creating an environment or when opening a file from somebody else. So if the specification are well defined, the first case can be covered most of the time. Then usually people add package one at a time when looking at some tutorial or help.

[isabela-pf]

@fcollonval thanks for the replies above! I'll need to get back to them in my next step of mocking up all the changes we've made at once for easier review. For now, here's

Deleting environments/ uninstalling packages

Deleting environments and uninstalling packages seems like a straightforward enough, but I still have a few questions worth resolving. These mockups show deleting environments as the example, but the pattern should match for uninstalling packages since they are both removals.

Ideal experience

The main expectation users will have when deleting/uninstalling something is for it to be removed from relevant lists and no longer usable. Maybe it seems obvious, but I think it’s worth noting this is the ideal.

Screen.Recording.2021-11-16.at.6.16.16.AM.mov

(Video description: The proposed Gator environment listing in the JupyterLab side bar with an environment selected. It shows the context menu, then deletes the environment with the button at the top of the sidebar. The environment is no longer listed. There is no sound.)

The main question is if/how meeting this ideal expectation is possible. I’ve heard that in Conda Store that making any changes, including deletion/uninstallation, initiates changes that may take some time to run. I would guess that other environment managers could have similar delays between the request and the actual deletion.

Is it possible to remove the item from the listing immediately even if it isn’t fully deleted yet in all the environment managers used in Gator? If it is, would there be any issues that could be caused by users not seeing that listing when it’s still at least partially there (for example an error in the deleting process)?

If items can’t be deleted right away

In case it isn’t possible (or could cause serious user problems) to have listed items removed from their lists when deleted/uninstalled, here are two ideas about feedback we could give users so that they understand why their expectation isn’t being met. To be clear, I’d prefer to have none of these options in Gator if we don’t need them.

Option 1

Just tell users that there is a delay. We could have a dialog that mentions the delay between making deletion/uninstallation requests and having them reflected (with a nifty Don’t show this message again checkbox). I am always hesitant about adding dialogs, but since this would be information users need immediately to avoid confusion I think it’s a reasonable approach.

Option 2

Change the look of the list item pending removal and include a tool tip that provides the message about delay on hover. In this case, I replaced the environment icon with an asterisk. This solution might also be helpful if there is a reason that removing an item from its list before its fully deleted could cause problems.

As always, feedback is welcome! It would be especially helpful to know if the ideal experience seems feasible or if I need to work on polishing these backup ideas to accommodate delays. Thanks!

[fcollonval]

Hey @isabela-pf

Thanks for the new sketch. We could hide the environment/package requested for deletion. But as you said, some points to take in mind:

• Deletion is not instantaneous (for environment it is quite fast but for packages it is not see next point)
• Removing one package may result in more removal (packages that depend on it). This means the new coherent environment state needs to be computed and this can definitely take a while and can fail.
• We should give the user a feedback on the long running process and its result (in particular if it fails)

For all the reasons mentioned above (that actually apply to most actions like creation, update, modification), the current extension is showing a toast notification informing the user something is going on.

Regarding the options, you are proposing:

• option 1: more dialog --> as you said let's forget about those 😉
• option 2: one thing I don't like with static indicators is that user don't get the impression something is going on. It is definitely stupid but the reason spinner, progress bar or some sort of animation is displayed everywhere on computer, phone,... is to give that sense of something is going on (even if it is completely fake as not linked to the task progression most of the time).

We could also display the item in disabled state (in addition to some change indicator) as the user should not be able to carry out any new action on that particular item.