Plugin and installation manager UIs #4952
Comments
|
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.
Plugins also could have some dependency, that version may create some problems. |
|
@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! |
|
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
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.
|
|
for example, one package requires 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. |
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 |
|
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:
My original answer is below too, with more details and more noise :D
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
Yes, we need an option in the UI. Technically, the user could use the input field in the bottom to say For the 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? |
|
much appreciate @isabela-pf since this seems to mostly pertain to the in-app interface, should we be moving this to There's a number of things that need improving/fixing in that dialog (#4937), I'm thinking about working on it soon, but would like to make sure that any other efforts are done in synchrony |
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? |
|
sure. Yeah if the action-item here would need to edit |
|
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
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
In action, this should look like the following.
Screen.Recording.2022-08-29.at.4.22.40.PM.movEven 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. |
|
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 So what about if:
Let me know if that makes sense! Thanksss |
|
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!
ProposalsThe 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? |
|
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. |
|
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. |
|
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. |
|
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
And listed in the plugin manager with installed and uninstalled plugins.
There are two reasons I’m hesitant to advise this solution
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. |
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! |
|
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 Without a collapsible sectionThe 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 sectionThese are the same images and have just about my same notes as above, they simply have the collapsible
|
|
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. |
|
@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 |
|
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.
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.
Or use a longer button with text like I think that covers the lingering questions I was running into, but please let me know if I've missed anything. Thank you! |
|
Hi @isabela-pf
Should be possible! Thanks a lot for working on this |
|
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:
|
|
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! :) |
|
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 |
|
I ended up getting responses to my last questions in meeting, so here are the notes and responses I'm making mockups off now.
|
|
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
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 UIJust 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 stylingAs 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.
|
|
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 installsKey question: When a user opens a bundled app of napari, what happens? Option 1
Option 2
Updating an active installKey question: what happens when a user tries to update the napari installation in the environment they are in? Option 1
Option 2
Option 3
Option 4
|
|
I LOVE the Preferences-based style! |
|
More thoughts now that I have some time :)
Now, your questions:
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?):
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:
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. |
|
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.
Questions!
Thanks in advance for the feedback! Card-based UI
Preferences StylingPer-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 |
|
Thanks Isabela! Some notes and answers:
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.
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.
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...
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.
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:
I guess @goanpeca has some ideas after his initial work on the installation manager. |
|
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 😆). To make it a little easier to follow, here’s a list of what’s changed between the last set of mockups and these.
All together that works like this: Screen.Recording.2022-11-01.at.11.50.52.PM.movOne 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. |
|
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)
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
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
Other PackagesRemove 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
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
|
|
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. |
|
this looks great @isabela-pf!! one minor wording suggestion, should the |
|
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)
|
Changes the plugin dialog to match the design discussed in #4952 Co-authored-by: Draga Doncila Pop <17995243+DragaDoncila@users.noreply.github.com> Co-authored-by: Gonzalo Pena-Castellanos <goanpeca@gmail.com> Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Grzegorz Bokota <bokota+github@gmail.com> Co-authored-by: Daniel Althviz Moré <d.althviz10@uniandes.edu.co> Co-authored-by: Peter Sobolewski <76622105+psobolewskiPhD@users.noreply.github.com>
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.
installcreateupdatelistremoveOther bonuses it sounds like we'd like to include are
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:
The text was updated successfully, but these errors were encountered: