Closed steff456 closed 1 year ago
With the latest commit, the save
button disables if the user only modifies the default environment. It reactivates if a further change is made in the channels or in the requested packages.
I feel like the text "Update Environment Build" isn't clear to end users.
I think "Make Active" is clearer since we use the word "Active" in the dropdown.
Along with that instead of called them "Builds" I feel "Versions" make more sense to an end user.
Another thought.
I don't think "Make Active" button belongs in the edit mode. We are not editing an environment just setting which one is the Active environment. I think it should show up in the default non-edit view but potentially only if you have permissions to make the change.
I think "Make Active" is clearer since we use the word "Active" in the dropdown.
I see; I think Change active build
is a better option (change -> the effective action happening)
Along with that instead of called them "Builds" I feel "Versions" make more sense to an end user.
Already raised some of this in https://github.com/conda-incubator/conda-store-ui/issues/269#issuecomment-1676386326 - the word build
is very conda-store specific and users will be more familiar with the concept of versioning and environments.
I suggested adding a description text under Change default build
to explain that builds are different versions of the environment (it also depends on how heavily we rely on the use of the word build in the rest of the app), but if we preferred to change it altogether then I'd suggest using:
Change active environment version
I don't think "Make Active" button belongs in the edit mode.
Smera suggested keeping this in the Edit
mode since that is where it best fits in terms of functionality (see https://github.com/conda-incubator/conda-store-ui/issues/269#issuecomment-1675130375) for the UX rationale
Already raised some of this in https://github.com/conda-incubator/conda-store-ui/issues/269#issuecomment-1676386326 - the word build is very conda-store specific and users will be more familiar with the concept of versioning and environments.
@trallard I'd be fine with us changing the terms we use in conda-store in the UI. I do think that environment version makes more sense.
I don't think "Make Active" button belongs in the edit mode.
I can't really make my mind on this one. I think it would be confusing in a "read only" view to expose something that could change the environment's state.
I do not think it should be in read only - Smera already made really good points on the original issue about why this is best suited in Edit and I agree with this being a better location.
But in general grouping workflows/concepts (edit, changes to settings, trigger builds) helps with user workflow streamlining and reduces context switching.
I have tested the feature and it works. I can test again after the UI changes in discussion above are done, if that's the case.
@steff456 - there are a number of changes/improvements needed:
Change default build
with Change active environment version
Change environment version
Change environment
button is deactivated if there are changes made to the specification (so basically the two workflows are mutually exclusive)I'm thinking about a new Nebari user who has no knowledge of conda-store. If they approach this button, will they know what "active" environment means? For example, maybe it just means active on the screen so they can edit it?
What if we added a little question mark circle that leads to a modal explaining how "active" environments work in conda store? That would include details like
@kcpevey I think that should be part of the more extended conversation regarding the workflow.
Plenty of improvements are needed in terms of notification/confirmation, documentation, etc., so let's keep this PR focused on splitting the workflows and taking the rest into a separate conversation.
The last commit implemented all the changes needed for merging this PR. Now when there's a change in the specification, the Change environment
button is deactivated,
Maybe after this PR we may need to revisit the disappearing of the Change environment
button, right now it only shows under certain conditions and it is not always visible in Edit mode which can be confusing.
Maybe after this PR we may need to revisit the disappearing of the Change environment button, right now it only shows under certain conditions and it is not always visible in Edit mode which can be confusing.
This is another part of the workflow review we need to do, I would generally prefer that this is disabled/enabled rather than appearing/disappearing
I just updated the variable names and double check that everything is working as expected.
Part of #269.
Description
This pull request:
Before
Now
Pull request checklist
Additional information
Please note that the screenshots were taken with different themes