Plugin and installation manager UIs

[isabela-pf]

I've been trying to understand what is needed of the manager UIs that have been mentioned on the roadmap and working group meetings. The following is the summary of the two main levels—plugin manager and installation managers—I've been hearing about from a functionality perspective.

Needed functionality

The following are the actions I believe we aim to cover.

• install
  • Installs packages to an environment.
  • In the installation manager, this is installing napari and its dependencies.
  • In the plugin manager, this is installing a plugin.
  • Users may need to install from remote or local sources.
  • Users may need to set channels, or explicit sources, for these installations.
• create
  • Create a new environment.
  • In the installation manager, this is the step prior to installing napari. In the context of the bundled app, users do not trigger this directly.
• update
  • Update existing packages in an environment.
  • In the installation manager, this is attempting to install the latest version of napari and its dependencies.
  • In the plugin manager, this is attempting to install the latest version of a plugin.
  • Updating has its own needs. This has more detail in napari/packaging#21
• list
  • List all packages in an environment.
  • In the installation manager, this is listing intalled napari and dependency versions.
  • In the plugin manager, this is listing all installed plugins and their versions.
• remove
  • Remove existing packages in an environment.
  • In the installation manager, this is uninstalling napari and its dependencies.
  • In the plugin manager, this is uninstalling a plugin.
  • In the context of the bundeled app, removal may be triggered by a user if they wish to uninstall napari or a plugin.
  • When updating a napari or plugin, users do not trigger this directly. Removal of the prior version automatically happens after the new install.

Other bonuses it sounds like we'd like to include are

• batch actions (ie. install or remove several plugins at once)
• making environment info available via the UI

Current status

With the existing plugin manager UI, I think we support all these main commands. Some more advanced additions (like specifying channels, batch actions) aren't yet supported.

We don't currently have an installation manager UI, so that is where most of the missing support is if I understand correctly. The installation manager also is not as immediate priority, I think.

What next?

With this summary, I would like to check a few things:

• Is there anything I'm missing? Is there other functionality I need to make sure and address?
• Does any of this sound inaccurate?
• Are plugin updates available via the current plugin manager?
• Is there anything that makes the bundled app version of this UI unique?

[Czaki]

For installation, the information about conflicts should be reported to the interface. Also, other cases in which installation fails should be properly reported in the interface.

Option to create the file with frozen version of napari environment (for example, to attach as supplementary material for reproducibility) and option to recreate such environment from such file (assume that user manually installs proper napari version). My motivation is the reproducibility of science.

• In the plugin manager, this is listing all installed plugins and their versions.

Plugins also could have some dependency, that version may create some problems.

[isabela-pf]

@Czaki thank you for adding these! By "conflicts" do you mean any error or specifically conflicts of dependencies needed to open the viewer?

I agree that I'd also like to make it a priority to surface the environment that napari is running in for reproducibility purposes. Making it produce a file does seem like the most easily portable way of this. And thanks for calling out the plugin dependencies!

[isabela-pf]

tl;dr: I’m unsure exactly where the gaps in the existing UI are and where immediate design help is needed. I don't know if @jaimergp or @goanpeca have thoughts on this.

---

I mentioned in my starting comment that I think the plugin manager that already exists in the non-bundled viewer meets all the actions we need for it to be functional in bundled app form. In revisiting with fresh eyes after a few days, it makes me unsure exactly where the design help is needed.

While there are things it sounds like we’d like to add (like batch actions, info about the environment that napari is in, dependencies for plugins), my understanding is that the first steps are to

1. ensure that we have what we need for the bundled app viewer to function
2. make the experiences between existing (not idealized) plugin managers in the bundled and non-bundled viewers as similar as possible.

In that case, I want to point out where I think the above actions are possible in the existing viewer to make sure we are on the same page.

install

• In the plugin manager, this is installing a plugin.

This is possible via the Install buttons on the left of the Available plugins section, by adding a URL to the input field at the bottom of the manager, or by dropping a source file in the input field at the bottom of the manager.

• Users may need to install from remote or local sources.

I believe the installation options above cover both these cases. Local installation seems only possible via the drag-and-drop as of now, though.

• Users may need to set channels, or explicit sources, for these installations.

This isn’t something I believe is possible at the moment. Would this need to be added for the bundled app UI even though I believe it’s considered an advanced feature?

update

• In the plugin manager, this is attempting to install the latest version of a plugin.

I’m not actually sure how this currently goes in the viewer as I have encountered a plugin update yet. At worst case, I imagine a user can uninstall the current version and reinstall the new version (since that what update does behind the scenes anyways).

I do hope we have another option I’m just not finding documentation on, though. :laughing:

• Updating has its own needs. This has more detail in napari/packaging#21

I don’t know the status of this work since it’s moved from the napari/napari repo to this napari/packaging one. Does the design exist in the viewer? Is it missing something that we've since identified as necessary?

list

• In the plugin manager, this is listing all installed plugins and their versions.

We currently list all installed plugins, available plugins, and their versions. This does not go too deep, as far as I’m aware. For example it wouldn’t show the dependencies or other versions available, for example. Do we need it to be that precise in the bundled app?

remove

• In the plugin manager, this is uninstalling a plugin.

This is possible via the Uninstall buttons on the left of the Installed Plugins section.

---

I hope that helps clarify where I think we are and why I think I'm not sure how to be most helpful here. Input would be greatly appreciated.

[Czaki]

for example, one package requires SimpleITK<2 and the second one SimpleITK>=2 (more real example here: https://github.com/napari/superqt/issues/100). Then plugin dialog should have a clear message about conflicting packages to not lead to a corrupt environment.

Even in the conda based environment, where conda could prevent such conflict, there is no clear message why the installation failed and no warnings that there could be a problem.

[Czaki]

I’m not actually sure how this currently goes in the viewer as I have encountered a plugin update yet

From time to time update work, Time to time, I need to uninstall the plugin and install it again. I do not have time to investigate differences and understand what happen (this is about conda based bundle).

[jaimergp]

From time to time update work, Time to time, I need to uninstall the plugin and install it again. I do not have time to investigate differences and understand what happen (this is about conda based bundle).

This is a bug with conda/mamba, which might consider that saying conda install plugin is already satisfied. We need to say conda install plugin=1.2.3 to make sure it does change things. We have a ticket for this, iirc.

[jaimergp]

Thanks Isabela! I'll try to add some comments/answers to your question. Overall I think the list is complete, we just need a couple of widgets and menus here and there to implement the missing features, namely:

• Install arbitrary versions of a plugin (and not just the latest), possibly via a dropdown?
• Distinguish, somehow, between packages that are available on conda or only on PyPI. A little badge like the npe2 one could work.
• Browse local files via UI dialog.
• The configuration dialog needs a way to list and extend custom conda channels and PyPI-compatible indices.

My original answer is below too, with more details and more noise :D

---

Local installation seems only possible via the drag-and-drop as of now, though.

If we are passing the string directly to the command, there's a chance just pasting the local path to the file works there (or maybe prefixed with file://). We could add a little button next to the input field (like [...] or Browse or similar?) to open a File Manager dialog for people to locate their packages maybe?

Users may need to set channels, or explicit sources, for these installations. This isn’t something I believe is possible at the moment. Would this need to be added for the bundled app UI even though I believe it’s considered an advanced feature?

Yes, we need an option in the UI. Technically, the user could use the input field in the bottom to say custom_channel::my_package with conda packages, but this does not work for PyPI-compatible indices (which would require -i http://url/to/custom/index). So yes, an option somewhere needs to be added (maybe in the preferences/configuration panel of the plugin manager?).

---

For the list actions, the two panels we have now are mostly enough! It does distinguish between Installed and Available. When an update is available for an installed plugin, it will be reflected in the UI with an "Update" button next to it.

However, we don't have a UI option of installing an arbitrary version of a given plugin. The Available panel right now lists the latest version of each non-installed plugin that is listed in the Hub API. I suggest that the version information is instead shown in a dropdown widget, defaulting to the latest version, but listing previous ones in case that's needed? Or is that too much clutter?

[tlambert03]

much appreciate @isabela-pf

since this seems to mostly pertain to the in-app interface, should we be moving this to napari/napari? or am I misunderstanding, and this pertains more to the constructor bundle?

There's a number of things that need improving/fixing in that dialog (https://github.com/napari/napari/issues/4937), I'm thinking about working on it soon, but would like to make sure that any other efforts are done in synchrony

[isabela-pf]

since this seems to mostly pertain to the in-app interface, should we be moving this to napari/napari? or am I misunderstanding, and this pertains more to the constructor bundle?

This is exactly what I was trying to figure out @tlambert03! It sounds to me like this is general in-app interface stuff, so I agree it might be more accurate in napari/napari.

Would you like me to add to napari/napari #4937, or does someone with permissions want to transfer this issue across repos?

[tlambert03]

sure. Yeah if the action-item here would need to edit napari/_qt/dialogs/qt_plugin_dialog.py, then it should be a napari issue. Will transfer

[isabela-pf]

Based on the above discussion, here’s my proposed UI amendments to the plugin manager. Recall that the minimum goal is to include UI that allows users to

• Select with plugin version to install. This changes the version statement to a drop down menu right next to the install button (the default selection is the most recent version).
• Label whether the plugin is available via conda or PyPI. This is labeled below the install button.
• Install plugins by browsing the local file system (ie. what the drag and drop method does, but without needing to mechanically drag and drop). This adds a Browse button next to the existing input field at the bottom of the dialog. The Install button for the field is now inactive until there is something in the input field.
• List the channel for a given plugin (if I’m understanding correctly listing is the only focus right now, and configuration is a future addition). This is now its own section on the plugin card.

To do this, I also had to made some changes on the plugin cards (what makes up each list in the plugin manager) in order to free up space for the additions. To make it easier to spot, I’ve

• Replaced the Website button on each card by making the plugin name a link to the website instead.
• Moved plugin author names to their own section, out from below the un/install buttons.

In action, this should look like the following.

https://user-images.githubusercontent.com/50221806/187315881-3d3ca985-2cc8-48b7-8851-2fad0f927cbe.mov

Even though I’d like to loop in some other changes to the plugin manager, I am trying to keep the scope of this work as narrow as it can be. Let me know if it seems like I’ve missed something.

[jaimergp]

Thank you so much @isabela-pf!

I am curious about the PyPI / conda implicit choices made in the UI. It makes me think that there's only one possibility, and sometimes packages will be available from both sources. I'd say conda should be preferred in the context of the bundle, while in the non-bundled napari maybe conda is not even listed (because a conda client cannot be found or whatever).

So what about if:

• The Install button, which would read "Install with {tool}", is also a split dropdown.
• The default choice will depend on the context: conda for bundle app, pip for non-bundled apps.
• The choices in the dropdown are also context-dependent: the package availability, and the tool availability.
• There's a chance we can make the 'channel' info / actions in the dropdown too?

Let me know if that makes sense! Thanksss

[isabela-pf]

Thanks for the update! I was going to ask if it was possible for installation to be available via both conda and PyPI, so this is good to know. I was definitely assuming that the preferred option was automatically chosen rather than a choice being necessary.

First, some more questions!

1. If installs are available from PyPI and conda, is the idea to remove a menu option when one isn’t available? It just seems like it’s taking up a lot of space to not switch.
2. I thought I had heard that we only needed to support listing the plugin’s channels as of now, and not changing them. That’s my mistake. For clarification, is it that an installed plugin can no longer be changed, but an available plugin needs a drop down for options? Or do they need drop downs in both states?
3. Back in #4145 we had discussed what a totally unavailable plugin would be like. Is this still relevant? I’m not sure if it’s currently implemented, or is something we need to account for in the case where a plugin can’t be installed on the current napari.

Proposals

The most straightforward is to add the UI as drop down menus like you mentioned. It is possible to make this fit even if it starts to leave very little room for names.

I dislike this approach because it seems like it prioritizes installation so much over discovering plugins (50% of the card is now dedicated to installation). I don’t think that is right because I’m assuming users don’t just install every plugin that exists, but that they are to review a whole list to find what is most helpful to them. I also dislike that it puts channels at an equal priority to version selection when I’ve heard that channels are something that is not likely to be meaningful to most users.

If possible, I think it could make sense to collapse the installation parameters. It still isn’t a situation I love, though, and I’m not sure that’s easy to implement. Still, here’s an idea.

Thoughts?

[jaimergp]

Would a split dropdown-slash-button alleviate the UI "weight"? Like this:

The dropdown would list the "Install with PyPI/conda" options, which would refresh the available versions dropdown.

[jaimergp]

Once installed though, I think we should stick to the chosen method. So the uninstall part doesn't need a dropdown. If a user wants to upgrade from a conda-installed version to a PyPI one, I'd say we don't want to encourage that kind of switch unless you know what you are doing; in that case, uninstall plus install again if you rrrreally want it? Open for discussion, though.

[jaimergp]

I checked whether Qt supports split-button-dropdowns and, guess what, here you can find @goanpeca talking about it some years ago 🤣 So yes, the widget is available.

• https://github.com/ColinDuquesnoy/QDarkStyleSheet/issues/187

[isabela-pf]

Thanks for the feedback! Having a split dropdown menu is definitely an option I can work with, and it does save space. If we do go this direction, I think it makes the most sense to have the split hold the install via options (ie. PyPI or conda). That would look like

And listed in the plugin manager with installed and uninstalled plugins.

There are two reasons I’m hesitant to advise this solution

• It implies the split option has greater importance or relation to Install than the others, which isn’t particularly accurate in this situation. Channel, version, and package source all are required to complete an installation.
• I’m not aware of this pattern anywhere else in the viewer. If we decide it’s still worth adding, we may have to work out some UX behaviors in greater depth if/when it breaks.

Alternatively, it may make sense to collapse some of the installation options (I gave more reasons in this comment). Since users can install with default selections already filled (as they do now), selecting their installation parameters is a more advanced use case. I think we can save ourselves a little space and visual noise by only disclosing these when requested.

I don’t think this solves the root issue, but it might work okay while we have to stick with the card UI. These cards don't scale well with the amount of info we are trying to fit in them, and may try and fit in the future with the amount of plugin data the napari hub has.

This could look like

And listed in the plugin manager with installed and uninstalled plugins.

---

If none of these seem fitting, I think we can make do with the last proposal as well.. Let me know how much you all think the split button adds to the experience.

[junxini]

Alternatively, it may make sense to collapse some of the installation options (I gave https://github.com/napari/napari/issues/4952#issuecomment-1233165909). Since users can install with default selections already filled (as they do now), selecting their installation parameters is a more advanced use case. I think we can save ourselves a little space and visual noise by only disclosing these when requested.

I really like how clean the card looks when you can collapse the installation info. Looking forward to the updated UI without the need for a "channel" within the card per @jaimergp's feedback yesterday!

[isabela-pf]

I'm back again with changes based on feedback! Some of it was in synchronous conversation, so please ask if any changes seem confusing or unexpected. One big change was removing channel selection from the card UI since it seems like it will require the user to work with the console anyways. This means that it has moved down to the input area that acts as a direct line to the console.

Because I haven't heard feedback about the technical feasibility of the collapsible Installation Info, I've provided an option with and without so we can move forward as needed. Other than that, these two options match in their other interaction patterns.

Without a collapsible section

The plugin version remains an isolated drop down, but the installation source becomes a split button. The author's name also has been tucked below the description; this choice helps keep all plugin exploration info to the left and all installation info to the right with some breathing room between them. This choice was made to support skimming the list of plugins.

When there is only one option available for installation source, the split button can disappear. There's no need for a one-option drop down. I'm not sure if we want to surface the source in this case, but I'm currently leaning towards no since we obscure this already.

Pulling from #4145, we also have an option for when a plugin is only available via a method the user doesn't have available (ie. it's only installable via conda, but the user does not have conda). I used what I believe was the final word on this issue, but if I made a mistake let me know. I'm not super sold on the tool tip text here, but I know we labored over that a good bit to make sure it wasn't overwhelming or unduly alarming.

And all combined in the plugin dialog, that would look like:

With a collapsible section

These are the same images and have just about my same notes as above, they simply have the collapsible Installation Info section. If we use this, I would advise having all installation options hidden there, not only the version control. This means the split button is not in these mockups, though if we have a compelling argument to include it I'm open. If we expect to have more installation options in the future, I'd recommend this approach because it might scale better.

[psobolewskiPhD]

I love the way the info is presented and the options, but I really wish the tiles for each plugin were expandable or something, like on click, with the extra info? They appear ~2x as tall as currently, so when filtering/searching you see fewer hits and need to scroll more. Disclaimer: I use a single 13" monitor full-time, so I'm perhaps overly sensitive to space issues.

[junxini]

@isabela-pf @jaimergp connected to align on the install dropdown options based on the following scenarios. sharing for visibility:

@ppwadhwa hopefully this will help drive clarity as you start the front-end build

[isabela-pf]

Following up on a few things! It looks like this idea is mostly working, but there are a few things I need to call out.

I really wish the tiles for each plugin were expandable or something, like on click, with the extra info? They appear ~2x as tall as currently, so when filtering/searching you see fewer hits and need to scroll more.

This is something I was worried about, too! You are absolutely right that these cards area about twice the height they were previously. So far I haven't found a balance of solutions that I've been hearing agreement on, but I think the collapse/expand could work. @goanpeca we've had some questions of whether or not it's possible to change the card size in the collapse/expand way; do you know if Qt can handle this?

---

I'm also following up on some other questions and mistakes I noticed in my last post.

1. The uninstallable a la #4145 design I posted above is almost correct, but I forgot to add that the install buttons would need to be deactivated.

   

2. The requested ? help is a hoverable tool tip designed as a space for adding more info about managing channels. I don't have a clear idea of what information is needed there as of now, but it's an open space. If people change their minds and decide it's not necessary, it's also easy to remove.

   

3. For installed plugins, I asked at one point if there was a limit on the width of the Update button since it appears to be determined by the version name. So far, it sounds like there is no limit which could give issues as we add more content to the limited space. I propose we either make this a generic Update button with the latest version listed below the button…

   

Or use a longer button with text like Update to latest version. Even though it is longer, it would no longer be variable so we could come up with a solution more confidently.

I think that covers the lingering questions I was running into, but please let me know if I've missed anything. Thank you!

[goanpeca]

Hi @isabela-pf

@goanpeca we've had some questions of whether or not it's possible to change the card size in the collapse/expand way; do you know if Qt can handle this?

Should be possible!

Thanks a lot for working on this

[isabela-pf]

With the plugin manager mostly rounded out, I’m going to be switching focus to the installation manager. I’ve started sketching to work out my ideas and their relation to other napari UI, and I have some clarifying questions for you all.

I have some basic actions needed from the installation manager at the top of the issue. To recap, that is:

install: installing napari and its dependencies. Users may need to install from remote or local sources. Users may need to set channels, or explicit sources, for these installations. create: the step prior to installing napari. In the context of the bundled app, users do not trigger this directly. update: attempting to install the latest version of napari and its dependencies.This has more detail in napari/[packaging#21](https://github.com/napari/packaging/issues/21) list: this is listing intalled napari and dependency versions. remove: this is uninstalling napari and its dependencies

1. Am I missing any other major actions the installation manager needs to include?
2. Are we surfacing napari installs that were not created by the napari bundle as well? Or does this manager only show installations via the bundle?
3. Are we only showing napari installs (regardless of method), or all environments detected?
4. From my understanding, you can’t access napari via the console if it was installed via the bundled app. Is there interest in keeping the the kind-of-console input area like the plugin manager has at the bottom of the dialog?
5. Are we enabling people to update dependency by dependency as well, or only on the napari level (with dependecies grouped under that)?
6. I know we wanted batch actions in the plugin manager and ending up cutting it. Do we want it in the installation manager?
7. Where would users access this dialog? What existing napari UX patterns do you all think it should match?

[ppwadhwa]

Hi @isabela-pf! On the installed plugins list, there is an update button that is blue above. All these buttons highlight on hover, what should be the highlight color of the blue update button?

Thanks! :)

[isabela-pf]

Hi @ppwadhwa, thanks for asking! I don't believe we have consolidated napari colors at this point in time, so my goal would be to have them match whatever napari currently does. My color picker tells me that the hover state color for blue buttons in the plugin manager is #1987D1.

[isabela-pf]

I ended up getting responses to my last questions in meeting, so here are the notes and responses I'm making mockups off now.

Question	Response	Impact on UX mockups
1. Am I missing any other major actions the installation manager needs to include?	- create is the only command that is installation manager only; - install is NOT on the installation manager; - term may be confusing (should not be used in UI), but we do need to be able to add things to an env; - remove is in the installation manager; - list is in the installation manager (list of envs AND list of packages per environment)this is a question of how we want to group it since there can be quite a lot; - htop as example; may need to show pinned (“protected packages”); - two things: change what you have. create, update, remove; - list what you have. list, info about base env.	Scopes the features needed
2. Are we surfacing napari installs that were not created by the napari bundle as well? Or does this manager only show installations via the bundle?	- showing only bundled installs (as far as they are aware)if we do end up having to list a mix, then we need to clearly show which we can take action and which are not; - currently beyond our responsibility to do more than that	List only bundled app generated environments/installs
3. Are we only showing napari installs (regardless of method), or all environments detected?	see above
4. From my understanding, you can’t access napari via the console if it was installed via the bundled app. Is there interest in keeping the the kind-of-console input area like the plugin manager has at the bottom of the dialog?	- Keep it!; - Need to explore further warnings needed. Maybe it needs to be enabled first because it can be dangerous.; - most impact will be on the bundled app installsRequired in NAP	Keep the not-quite-console from the plugin manager
5. Are we enabling people to update dependency by dependency as well, or only on the napari level (with dependencies grouped under that)?	- Focus on just napari updates (meaning create new env + new napari install of a newer version); - Plugins can be updated within an existing environment; - This will happen in plugin manager, but may be surfaced in installation manager in the future; - Basically think ahead and leave room for it, but don’t focus on it now.	- Update feature and UI is env/napari install is first priority; - Leave room for plugins to be updated in the future
6. I know we wanted batch actions in the plugin manager and ending up cutting it. Do we want it in the installation manager?	- Wait!; - More important in plugin manager.; - Out of scope for now	No batch actions
7. Where would users access this dialog? What existing napari UX patterns do you all think it should match?	- Reference other update managers (past screenshots); - Sidebar interest; - Example of installation manager (here); - Pytorch website example (on how to select what parameters you need, specific for napari.org website)	Check sketches against these references
8. What is the difference between plugin and installation manager?	- Installation sees multiple env of napari and can work with multiple packages. It’s one level above plugin manager. Plugin manager is one view below installation manager	Create visual relationship between the two managers (perhaps some kind of nesting?)

[isabela-pf]

Hooray! I have a first round of ideas for the installation manager, and feedback is much needed. It would be especially helpful to hear your thoughts on

• UI language/how features are described.
• What information is listed, especially if anything is missing.
• Whether a status like “active” to indicate an install in use makes sense or is helpful.
• If there a preferred way to list packages? I imitated the command line styling, but I don’t know if there could be useful additions (like filtering).
• Anything else, of course.

I have two visual directions below, but based on these discussions I expect we want the installation manager to match the current look of the plugin manager. I’m providing the other option more for long-term consideration since, as I’ve mentioned, the card-based UI brings some limitations for both the plugin and installation managers.

Card-based UI

Just like the plugin manager, this UI has a series of cards per environment/bundled app install. The primary difference is that there is only one long list of cards rather than the split that the plugin manager has.

It also preserves the console-like UI at the bottom of the plugin manager.

Preferences styling

As an alternate option, I think we could consider following the visuals of the Preferences dialog. Especially with the nesting of environments > packages > napari installation > plugins that is happening in the background that might be surfaced in the future.

[isabela-pf]

When working on this round, I realized I had some UX questions to sort out as well. Below are two major questions I had with possible user flows as examples. Please let me know which ones make the most sense to you.

Opening bundled app installs

Key question: When a user opens a bundled app of napari, what happens?

Option 1

1. Open “napari” from relevant OS menu.
2. The last-used version of the bundled app is used.
3. Users navigate to the installation manager (in the python section of the OS menu) if they wish to use a different version or make changes to the install.

Option 2

1. Open “napari” from relevant OS menu.
2. The installation manager opens and prompts users to choose an install.
3. The chosen install opens.
4. Users can still navigate to the installation manager (in the python section of the OS menu) if they wish to use a different version or make changes to the install.

Updating an active install

Key question: what happens when a user tries to update the napari installation in the environment they are in?

Option 1

1. Pop up dialog appears with prompts to “Update now,” “Update on quit,” or “Cancel.” There should also be a check to save preferences and not ask again.
2. Update proceeds as requested.

Option 2

1. Update triggers an update based on the user’s preset preferences of updating now versus on quit.
2. Dialog appears before update if it is not an immediate update (ie. on quit.)

Option 3

1. User has multiple options to update in the interface. “Update now” or “Update on quit.”

Option 4

1. User cannot update an install while it is open. The option is disabled until they deactivate the environment or are in a different one.

[jaimergp]

I LOVE the Preferences-based style!

[jaimergp]

More thoughts now that I have some time :)

• I am definitely more inclined to the Preferences-based style.
  • The "Open in Plugin Manager" button makes me very happy :) It makes a lot of sense!
  • What does the "Active" checkmark mean next to napari v0.4.16. That it's running? Or that is the default version?
  • I don't know if the installation manager needs an "Update On Quit" button, since it won't be tied to a running napari instance and can operate very much on its own.
  • We need a button to trigger diagnostics or reparation tasks. Not too prominent, so maybe at the bottom it's enough.
  • We'll need a button somewhere (bottom sidebar?) to open a Preferences dialog for this UI :) Alternatively, the sidebar can be a tree menu, where the first entry is "Available installations", and then we have other entries like Preferences.

Now, your questions:

When a user opens a bundled app of napari, what happens?

I'd say that if we have several coexisting naparis, each version will have its own shortcut/menu item (this is the case right now). If we agree to this, then we don't need the "Active/Inactive" UI elements to mark them as default.

We can also have one menu item per version, and an unversioned shortcut that opens the default napari.

If we don't want multiple shortcuts and just one (bad idea in my opinion), then the workflow could look like a mixture of options 1 and 2 (let's call it 1.5?):

1. User finds the napari menu item and opens it
2. If there's only one napari version installed, open that one.
3. If there's more than one:
   1. If not default option is found, prompt the user to choose one and offer the possibility of "remembering" that choice; e.g. marking that one as the default.
   2. If there's a default one, open it.
4. The user can always open the installation manager separately (this is a different shortcut) to change the default installation.

what happens when a user tries to update the napari installation in the environment they are in?

Since the installation manager is a separate process, there's no need to consider "on quit" options. An available update can be notified within napari itself, and opening that notification would open the installation manager as a separate program. The user can choose what to do then:

• Update now (create the new environment) and mark the previous one for deletion if successful.
  • If the new environment is created successfully, the old one will be scheduled for deletion. This might happen instantly if possible, or we might need to wait until the user closes the running napari instances, or maybe after reboot (sometimes needed on Windows).
• Snooze the update to be reminded later (like Docker does?)
• Ignore this update permanently.

---

Let me know if you need further clarification. We might possibly need to involve the steering team here for the one or multiple shortcuts, but we can wait until we have a more concrete proposal! (Steering team, if you are reading this, that doesn't mean your feedback is not appreciated now, more like we don't want to bother too much until the proposal is more concrete, so please feel free to add comments if needed!).

Thanks for the beautiful work @isabela-pf, it already looks better than what I had in my head.

[isabela-pf]

But wait, there’s more! Between the bundled app/packaging working group meeting and the feedback in comments above (thank you, @jaimergp!), here are changes made in this round of mockups.

• Remove the environment name section. There can only be one install per version, so the napari version alone is sufficient to tell the installations apart.
• Remove the not-quite-a-console. It brought up a number of questions about how it would interact with each environment and how that would be communicated, and doesn’t seem necessary at this point. For now, I kept the Show Status in case the progress on an install or logs might be useful. It’s usually easier to remove the UI than to make space for it later.
• Updating UI is done outside of any single installation. It’s phrased to describe that it is in fact a new installation. Right now, it consists of a label, drop down menu, and button. If this makes it through this round, I need to go deeper into the UX for how it will work.
• I did add a Restore option. Some feedback requested it was removed, and some was in favor. Once again it is easier to remove than to add. Right now it is only a button and a description.
• Switch some of the language used. For example, when a napari is in use it will be labeled as “Running” and have a “Quit” option available.
• There is now a default napari option.
• Add an option to remove an environment. I’ve called it “Uninstall.”
• I’ve added “Open Install Preferences” per request, but this needs more thought for sure. I’m not sure what Install Preferences exist! I made a guess, but confirmation would be helpful.

Questions!

• Would a “Jump to napari” option be helpful for running naparis? Basically it would bring up the relevant window. I could imagine this being helpful if you have several naparis open and want to be sure you are working in the intended one?
• I know with the parallel installs there has been some discussion about disk space issues. Is the size of the install useful info to include?
• As mentioned about, what Install Preferences are needed?
• Can we sort out the status of Restore since I’ve heard mixed feedback? One side can be summarized as “restoring broken environments is useful but not the minimum needed, so it should be postponed.” I believe the other side thinks it makes sense as a utility and ties in with existing environment abilities easily enough.

Thanks in advance for the feedback!

Card-based UI

Preferences Styling

Per-environment information.

Install Preferences. This has an option to add a new installation via drop down selection of napari versions, calls out a new version of napari is available a la update, and allows users to select a default napari.

cc: @Lisa-CZI

[jaimergp]

Thanks Isabela!

Some notes and answers:

Remove the environment name section. There can only be one install per version, so the napari version alone is sufficient to tell the installations apart.

This might not be true in the future, if we allow users to install "custom napari distributions" if they find that two plugins they need are not co-installable. Or if they want to have per-project naparis or something like that. So maybe we do keep the name, since "removing is easier than adding"? :D The default name might still be "napari vX.Y", though.

Can we sort out the status of Restore since I’ve heard mixed feedback?

I'd be in favor of keeping it, but I also agree it's not a priority. I would not name it "Restore" though, because from the implementation point of view we might not be able to guarantee you get the exact same thing you had at the beginning. Restore gives me "travel to the past" vibes, but "Reset" would be more neutral in those expectations? Might be overthinking this, though.

Would a “Jump to napari” option be helpful for running naparis?

I'd say it's useful, but also not really a priority, and I am unsure how it would work implementation wise across operating systems. Might be trivial on Windows and MacOS, but not on Linux with different desktop environments...

I know with the parallel installs there has been some discussion about disk space issues. Is the size of the install useful info to include?

Useful, yes, but we need to think how we want to present this info. conda environments do not copy files. They just provide "views" (symlinks) of a central cache. So the easy-to-understand information is how much space ALL installed naparis are consuming globally. For example, all naparis will share Python, Qt and some other core libraries, but they might require different plugins.

This disk usage report could use a "Clean unused files" or similar to prune the cache and recover some space. Sometimes users will uninstall plugins, but the cached files will remain by default.

As mentioned about, what Install Preferences are needed?

We might need to sit down and think about this, but I feel it's going to be a "we'll add as we see a need". That said, I can expect some like:

• List of default conda channels.
• Environment variables table (they can be used to control certain advanced conda options)

I guess @goanpeca has some ideas after his initial work on the installation manager.

[isabela-pf]

I’ve been trying to iron out the full user flow for how this UI string together from download to update prompts within a given napari. In the meantime, I’d like to get some feedback on what we talked about most in the last bundled app/packaging working group meeting: what it looks like to roll back an environment while preserving installed plugins. In the UI, I’m calling it Revert Installation for now (naming feedback welcome :laughing:).

To make it a little easier to follow, here’s a list of what’s changed between the last set of mockups and these.

• Based on @jaimergp’s and feedback here and the feedback in the working group meeting, I’m moving forward with the Preferences-style UI.
• Moved the Installation manager to its own dialog.
• Emphasize update info and deemphasize the add new install UI.
• Add Revert Installation as its own section with a description and rollback version select.
• Add Source section to the plugin list (since the information is now revealed in the bundled app work earlier on this issue)

All together that works like this:

https://user-images.githubusercontent.com/50221806/199527343-15e3491e-1b7a-4c5e-ab49-2664c360cceb.mov

One by one, here is the napari Installations section—basically the preferences and global operations. This is an area I still don’t feel confident in feature scope, though I do want to thank @jaimergp for answering some of my questions on that. Right now it is the update information (though which napari it is replacing to update is unclear to me), add a new napari version, and manage default designation for existing installs.

Within a given installation, there is basic installation information, status (ie. running or not), and open/quit. Plugin listing, other package listing, revert installation, restore, and uninstall are grouped below. I've shown the full UI, but I would like this to scroll if possible.

My main goal at the moment is to figure out what areas are set and what areas need more work. I’ll follow up with the in-meeting feedback about this so it is documented, but know asynchronous feedback is very welcome too.

[isabela-pf]

We ironed out a lot of final details in this week’s bundled app/packaging working group meeting. I’m going to report back all the decisions we made so people not at the meeting can weigh in. Thanks in advance for giving it a review!

napari Installations (top level of sidebar)

• Update info: good as-is.
• New install: remove.
• Default version: remove.

Because there are no baseline preferences we want to keep, and updates will only be available some of the time, this screen is being cut. Update info will appear on the top of the napari version info page.

napari Version/Install Info (nested levels of sidebar)

Install info

• Version: good as-is
• Default and status (ie. Running): remove.
• Open/Quit: Keep open, remove quit. Open behavior will depend on OS expectations for what opening that application will mean (for example, does it switch to the already open window or open another instance of that application?)

In place of the default/status section, the proposal was to add the last modified date of the install and update status (ie. is this the most recent version of napari or not). This will fit better with the changes to the revert/roll back feature described below because the last modified date will now be more important.

Plugins

• Button to open in plugin manager: remove (nice to have and may be added back, but may require too much effort for this timeline).
• Plugin list: Change source from conda to conda/conda-forge, adjust alignment since the list is not monospaced, add Build section to the list. The Other Packages section will also be moved into this, more details in that section.

Other Packages

Remove this section. Add the ability to show/hide non-plugin packages to what is currently the Plugins section.

The motivation was that Other Packages takes up a good bit of space with limited benefit. It is a long list that can already be found in napari Info for bug reports and support. Much of it won’t be meaningful to people in cases other than bug reports.

Revert

• Description: needs to be updated to suit the snapshot behavior (discussed below).
• Version/select: remove.
• Button text/feature name: needs to be updated to suit the snapshot behavior (discussed below).

In the meeting, we spent a good amount of time discussing how reverting would work from both an implementation and UX perspective. Because the goal is to limit environment management and provide more of a single install with options to control that installation, the plan is to move forward with a feature that keeps a snapshot of the users most recent major version change. This snapshot will be what they revert/roll back to. They do not have multiple snapshots to choose from.

With this, we’ll need to update the description text and replace the version select with a prefilled description of the snapshot they’ll be rolling back to (with date and version listed).

Installation Actions

• Reset: good as-is.
• Uninstall: keep, but add a description to make it clear what the scope of uninstalling is.

[isabela-pf]

Following up on the previous comment, this is what the changes would look like all together. The main edit I would still expect is if there are inaccuracies in the description text.

I would like to track this bundled app user flow from installation to updates (including work in napari/packaging #21), but for now I think this covers the new additions.

[junxini]

this looks great @isabela-pf!! one minor wording suggestion, should the Revert Installation button be changed to Roll Back Installation? that way it's consistent with the description using the word "roll back" since in the meeting a few people pointed out that "revert" has a different connotation.

[aganders3]

Just throwing this out as another option to consider: what about "Restore Snapshot" or "Restore from Snapshot"?

[goanpeca]

Just throwing this out as another option to consider: what about "Restore Snapshot" or "Restore from Snapshot"?

That could also work, however it might give the idea that there will be many snapshots to choose from (which there will be, but we will not expose them, just the last one available)

Snapshot might be a bit too technical a term? (just realized the word snapshot is on the description text whoops!)