-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ENH] - Improvements to change default build workflow #269
Comments
@costrouc I believe we can switch the current build from the "Edit" environment screen: Screen.Recording.2023-08-11.at.3.17.06.PM.movI do think this isn't very intuitive, and moving this functionality to the main screen (pre-edit) will be better. Moreover, the "Save" button is active when we switch to a different version, and clicking on it will trigger a re-build (although it's not required for the previous version activation). We can at minimum disable clicking on Save if the only action was switching versions: Screen.Recording.2023-08-11.at.3.21.28.PM.movWe can ask @smeragoel for thoughts on UX. :) |
|
This is a concept we inherit from
In a user story: As a conda-store user, I want to be able to choose or change my default environment so that I have my most commonly used dependencies available at all times or update my environment with recent updates.
This should be a persistent choice until the user makes a change |
Thanks for the info @trallard! Based on this, I'd say that it's better to place this functionality in the edit mode rather than view mode. Here's why:
To address what @pavithraes mentioned:
|
I agree with @smeragoel - it makes more sense to have this functionality within the Edit view unless there is a dedicated settings/configuration section (I do not think so... But might need someone to confirm this). I wonder if we should go beyond changing the text to "Change default build" and add some description text as well. I am +1 on disabling the Save button. |
Adding more thoughts
I am thinking we could perhaps do with a workflow where the user triggers a new build of an environment and could be presented with a checkbox to "set/select as a default environment built." |
I think this happens automatically right now. I mean, the latest build is automatically activated unless we manually set a different (previous) one. |
I've been digging into this issue today, and I have more information about what's happening underneath in the code. So apparently, users can have different builds where for each build the packages and channels can vary as well as their versions. This is why, the In this case, I feel it makes sense to leave the Also, for implementing this case, I would have to add more checks to the general I would love to here opinions, for now I will open a PR with the change on the label in the page. |
That behaviour is expected @steff456 basically every build is, well a different build or version of a given environment thus is expected to have different versions of a package and/or new packages. The Save button is right now only triggering a new build, not only changing the choice of a build itself. Disabling the button when a user makes an intentional change of a build will and should only prevent an unnecessary build. |
+1 to description text. It's always better to err on the side of caution and be very explicit with what a function does, rather than assuming that users will understand it.
I want to clarify on the intention behind the checkbox. From what I understand, setting the latest build as the default build is implictly done through the |
Lol this workflow/UI pattern needs to be clarified. Going from the video in this comment: #269 (comment) Scenario 1:
Scenario 2: My primary thoughts about the current implementation:
High-impact changes should not pass silently - they should be an intentional choice by the user, and these changes should be confirmed somehow. The current behavior of the Save button is not explicit nor matches common patterns of 🦄 Tania wants to set a new default environment: So basically we need to make whatever is happening explicit - now y'all get a 🍪 for reading all the way here |
The behavior in scenario 2. is what is currently happening. I feel the fact that both changing the default environment and making changes to it in the same place is what makes this interaction confusing. Maybe we need to rename the Save button or add some description to the UI so that the user understands what pressing the button actually does. Also, I'm thinking that maybe a more descriptive title to the section where the packages and channels are modified can help. |
With the current implementation both scenarios are possible. Hence the original suggestion of disabling the Save button |
PR #271 has now the behavior for the Save button as discussed. |
Currently the "Save" button does several things implicitly. It saves the new specification (env description and env.yaml). It then also automatically triggers the building of the environment. After the new environment has completed building successfully the newly built environment becomes the new "Active" environment. The save button should only be applicable when changing the specification. Changing the default active environment should never impact the environment specification. If you change the specification then the "make active environment" button needs to be disabled because. a. the env doesn't exist yet to be made active anyway @smeragoel (c) is current behavior and maybe that is the most common use case but maybe it needs revisiting. |
I think the most important thing to note is the "implicit" behaviour. After changing the specification and clicking on save there is no explicit indication of
The current implementation has both the ability to select an available environment and build a new environment (even without specification changes) enabled at all times which obscures this even further. The fix Stephannie is working on aims to separate these two explicitly by having only one or the other enabled at a given time. |
Feature description
Currently there is a dropdown to view all available builds. There should be a button or similar which allows to change the build. For context the "old" jinja static html UI has this feature
The "checkmark" icon switches the current build making a REST api call to
PUT /api/v1/environment/<namespace>/<environment-name>/ {"build_id": <build-id>}
Value and/or benefit
Core feature of conda-store that needs to be exposed.
Anything else?
No response
🧰 Update based on recent discussions
Tasks
The text was updated successfully, but these errors were encountered: