ENH - Improve default build selection workflow

[steff456]

Part of #269.

Description

This pull request:

• Changes the label in edit mode so that the user understands that changing an option in the combobox will change the default build

Before

Now

Pull request checklist

• Did you test this change locally?
• Did you update the documentaion (if required)?
• Did you add/update relevant tests for this change (if required)?

Additional information

Please note that the screenshots were taken with different themes

[steff456]

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.

save.mp4

[dharhas]

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.

[dharhas]

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.

[trallard]

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 #269 (comment) - 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 #269 (comment)) for the UX rationale

[costrouc]

Already raised some of this in #269 (comment) - 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.

[trallard]

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.

[pierrotsmnrd]

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.

[trallard]

@steff456 - there are a number of changes/improvements needed:

• Replace Change default build with Change active environment version
• Button should be Change environment version
• Ensure that the Change environment button is deactivated if there are changes made to the specification (so basically the two workflows are mutually exclusive)

[kcpevey]

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

• Environments on Nebari are versioned, making it easy to roll back to previous versions. You can modify an environment and build a new versions, and all the previous versions will still be available.
• the active environment will be the version used by jupyter notebooks and used in the terminal when the environment is activated
• WARNING: if you set an environment to "Active" (or build a new version of an environment) that you are currently using in a jupyter notebook, you'll need to switch to a different environment and switch back to get the newly "Active" environment.

[trallard]

@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.

[steff456]

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,

dis.mp4

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.

[trallard]

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

[trallard]

Thanks @steff456 this looks almost ready.
I made a suggestion to rename variables to best reflect what they are for/when they are used. But I ran out of time to do all the search and replace.

Can you please do a thorough check/search/replace on your end so we can merge?

[steff456]

I just updated the variable names and double check that everything is working as expected.