[ENH] - Improvements to change default build workflow

[costrouc]

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
- [ ] Change Dropdown text - "Change default build"
- [ ] Add a description before the Dropdown (see issues below)
- [ ] Disable "Save" button if the environment is changed

[pavithraes]

@costrouc I believe we can switch the current build from the "Edit" environment screen:

https://github.com/conda-incubator/conda-store-ui/assets/33131404/9a74eda1-2dbf-41d8-ac13-cc53636e808a

I 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:

https://github.com/conda-incubator/conda-store-ui/assets/33131404/f9935686-eed8-4225-a8e3-2f7b9efb53ed

We can ask @smeragoel for thoughts on UX. :)

[smeragoel]

1. What does "default" build mean?
2. What is the scope of changing the default build? Does this change change the default build for all users (environment-level change) or only for that user (user-level change)?
3. Does the change only apply for the current session or is it more "permanent" (until you change it again)?

[trallard]

What does "default" build mean? Does this change change the default build for all users (environment-level change) or only for that user (user-level change)?

This is a concept we inherit from conda; there is an environment that is automatically initialised/activated (for a given user in this case). From conda, there is always an active environment so that the user can start working without worrying about activation steps.

What is the scope of changing the default build?

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.

Does the change only apply for the current session or is it more "permanent" (until you change it again)?

This should be a persistent choice until the user makes a change

[smeragoel]

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:

• Clearer Purpose: When people are editing settings, they understand better what changing the default build means. So, it makes more sense to offer this option when they're already in the mindset of making changes.

• Right Context: Editing mode is where users expect to customize things. Changing the default build is like adjusting a setting, so it fits better in the edit mode.

• Avoid Accidents: If it's in view mode, someone might accidentally change the default build without meaning to. In the edit mode, users are more careful since they know they're making changes. Even though changing versions back is easy, it's possible users wouldn't even realize they are changing a configuration.

• Consistency: If other configuration actions are already in edit mode, putting this option there keeps things consistent and familiar.

• Saves Time: Placing it in edit mode streamlines the process. Users don't have to switch between viewing and editing just to change settings.

To address what @pavithraes mentioned:

• I think one of the reasons it's not clear that the option to change build exists is because of the copy used. If we use "Change Default Build" above the dropdown rather than just "Builds", I think it'd be clearer to the users.
• Regarding the behaviour of Save button, I think it's a more difficult question, but I agree with your recommendation of disabling the Save button, especially because the Update Environment Build and Success toast already notify the user that the change has been made.

[trallard]

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. Many people will be familiar with conda concept of base environments but we are using different terms (build vs. environment) and giving the user additional information or hints would improve that first user experience.

I am +1 on disabling the Save button. But if - and only if - we wanted to give the user the option to create a new build and set that at the default once completed then this would need to be perhaps a separate option/button. Which I kind of feel is what the intention of the Save button was in the first place but was not adequately implemented

[trallard]

Adding more thoughts

But if - and only if - we wanted to give the user the option to create a new build and set that at the default once completed, then this would need to be a separate option/button. Which I kind of feel is what the intention of the Save button was in the first place but it was not adequately implemented

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." This will need UX input from @smeragoel and accounting for in-design (WDYT?)

[pavithraes]

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.

[steff456]

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 save button is being active when the user changes among the available builds.

In this case, I feel it makes sense to leave the save button behavior as it is, because at the end changing the build in the combo box may bring different packages and channels to the default setting and I think it is important for the user to see what's changing.

Also, for implementing this case, I would have to add more checks to the general edit form and it will start to get really complex and I'm worried that it may introduce an undesired case.

I would love to here opinions, for now I will open a PR with the change on the label in the page.

[trallard]

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 change to a different build is and should be an intentional user change and right now confirmation is given by a toast. So the Save button is not needed to confirm or apply the change itself, in other words the Save button is redundant in this case. The user should be able to see what is changing through the different builds elsewhere - the change of the default build is an intentional change triggered by the user.

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. There is no additional validation needed anywhere else so I do not see the need for added complexity like you mentioned.

[smeragoel]

I wonder if we should go beyond changing the text to "Change default build" and add some description text as well. Many people will be familiar with conda concept of base environments but we are using different terms (build vs. environment) and giving the user additional information or hints would improve that first user experience.

+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 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." This will need UX input from @smeragoel and accounting for in-design (WDYT?)

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 Savebutton. The checkbox will make this process explicit. The user can control whether they want the current/latest build to be set as default by interacting with this checkbox, and the Save button will be activated accordingly. Is this correct @trallard?

[trallard]

Lol this workflow/UI pattern needs to be clarified. Going from the video in this comment: https://github.com/conda-incubator/conda-store-ui/issues/269#issuecomment-1674485856

Scenario 1:

1. User selects an Available build from the combo box -> Clicks on Update environment build button
2. Confirmation toast appears to confirm change
3. Build status changes from Available to Active on combo box

Scenario 2: Start from completion of step 3

4. User scrolls down and clicks on Save
5. This triggers a new build (this can be confirmed by going back to the combo box where a new build appears with the status Building
6. Once this new environment is created then it is automatically selected as the Active environment (basically, the choice I made in Scenario 1 does not matter)

My primary thoughts about the current implementation:

1. Scenario 1 is a complete and easy-to-follow workflow - the user makes an intentional choice and gets confirmation of the change ✅ actions are explicit (in this scenario, we do not need a Save button at all)
2. Scenario 2 is confusing:
   3. The Save button does not perform a Save action. Instead, it triggers a new build, and that new build is then Activated - this does not match my expectation of a Save action.
   4. If this is the first time I interact with this interface, then clicking on the Save button will perform a silent change; I do not get any warning about a new build being created (unless I, by any chance, go and check the combo box, but why would I do it when I already made a selection and clicked Save?). So I will close the window or change tasks, and I will undoubtedly get a different active build from what I was expecting (and then I cannot trust my dependencies).

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 Save. I suggested a checkbox (honestly, the component does not matter. It can be anything), but really what I want is something like this:

🦄 Tania wants to set a new default environment:

1. Choice: use an existing one or build a new one
2. Make my choice (Whatever choice or preference this has to be intentional and user-driven; Tania is in control and knows what she will be getting from her choice)
3. 🎉 I get confirmation that my change was made OR that my new environment is built and will be activated when successful
4. I can now trust my environment because I know what I am getting

So basically we need to make whatever is happening explicit - now y'all get a 🍪 for reading all the way here

[steff456]

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.

[trallard]

With the current implementation both scenarios are possible. Hence the original suggestion of disabling the Save button

[steff456]

PR https://github.com/conda-incubator/conda-store-ui/pull/271 has now the behavior for the Save button as discussed.

[dharhas]

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 b. it can't be made active if the build fails c. it becomes the default environment automatically after it is built successfully

@smeragoel (c) is current behavior and maybe that is the most common use case but maybe it needs revisiting.

[trallard]

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

1. The environment is being built and
2. Upon completion this env will be activated

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. Agree that the whole workflow (and consequently the UI) might need rethinking but in the meantime separating those workflows (change env or build a new env) should start moving us in the right direction