As a user, when I'm managing environment variables with GitLab, I want to be able to see, search, or create a scoped environment in the UI, so that I can quickly define the correct environment for my variable.
UX review for MRs that include user experience changes - mandatory for frontend that has impact to UI/UX
Update SSOT in issues:
Update prototypes of deliverables
Add link to documentation
Create new issues for follow up and open scope
Further details
Today, when creating environment-specific variables, if the user types in something like production for the environment scope, the box returns the options No matching results and Create wildcard production.
Showing No matching results kind of makes sense given that a production environment doesn't exist yet. User can proceed by clicking the Create wildcard production. One of the questions raised originally was: What does creating a wildcard even mean? Especially since this isn't a wildcard at all. A wildcard would be production*.
In this case, the user should not be creating a new production wildcard, but production*. The asterisk is implied, and that causes friction when interacting with the UI.
If the user has an existing environment called production, the option is displayed in the UI, and the user can select it and proceed. Existing environments are displayed in the searchable dropdown option.
A recent change !27699 (merged) removed this pattern from the UI. We need to investigate how to reintroduce the searchable dropdown, and why the interaction is no longer available.
fetch environments names set for other secret variables
populate the list with entries from 1 and 2
allow also arbitrary entries, so users can add environments that don't exist yet
What do you think about this flow? If the user selects one of the existing entries, the input field will be prefilled with the value. If the direct input doesn't match any, it will saved as-is, without any further action to do.
It is a little different from other places where we are using the same control, but probably it is worth to be addressed so we can use it in other places, like environment selection when adding a Kubernetes cluster.
Add a table header to the variable list, with column titles: Variable key, Variable value, Protected and Environment scope. This is to gain some horizontal space by removing the Protected label from each row as well as better organization.
Replace the Environment dropdown button with a plain text input. When creating a new variable, this input will be empty by default. If the user saves without specifying this field, a * will be added.
When the user clicks on the input field, an autocomplete dropdown appears. It would work similarly to the issue/MR search.
The options in this dropdown will be:
* (All environments)
Project environments
Environment names used in other variables
All these values are shown without distinction because I think separating them in different sections would indicate to users that they can only select one of the values in the list, and would deter them from trying to type in their own string.
When the user starts typing, any environments that match the string will be highlighted in bold.
A new row appears at the bottom containing the exact string the user typed in double quotes. This way, we indicate that they can use that as a custom value.
This dropdown should be navigatable with the arrow keys and selectable with the Enter key (same as issue/MR search)
If the user selects their custom option, it gets displayed in plain text form and it will be possible to select it from the dropdown when a new variable is added in the future.
@dimitrieh Could you help me out with this issue while I am away next week? If the proposal is accepted, the description needs to be updated with the contents of my last comment. Thanks a lot!
Great concept @cperessini I have moved it to the description
Replace the Environment dropdown button with a plain text input. When creating a new variable, this input will be empty by default. If the user saves without specifying this field, a * will be added.
I wonder how this is going to feel. Let's check this out in the ux review of the merge request. I wonder if just having the default value be * (All environments) where (all environment) is not part of the real value so to say is a more transparent option
I wonder if we can make it additionally clear that wildcards are supported also in the form of prod* etc. This should at least be documented cc: @axil
I have another question for wildcards. The UI says: Create wildcard production, so is the asterisk (production*) implied or not? I need to create a variable that will apply to all environments starting with review/. Do I enter review/ or review/* in the environment scope field?
Wildcards (*) can be used along with the environment name, therefore if the environment scope is review/* then any jobs with environment names starting with review/ would have that particular variable.
I'm adding a help line text to the dropdown so we can link to those docs:
@okoghenun Just updated the description. There's a guideline that mobile dropdowns should be full-width. I know that settings pages have a weird margin situation on the right side, so it's okay if the dropdown needs to be limited inside this margin.
@bikebilly@cperessini I'd like to confirm if these new design will also apply to CE because the delete button on mobile will look out of place as there is no option to provide 'Environment Scope' in CE.
@okoghenun this will not go in CE. This is what CE looks like right now (with a - icon instead of the proper trash icon)
I agree that the placement of the icon is less than ideal, but it works for now, so let's keep moving with this issue. We can create a separate issue to move the icon to a better place on mobile
@darbyfrey@ogolowinski calling out the MR for this issue that was created a while back. Please let us know if frontend should prioritize the review in upcoming milestones. !5974 (closed)
As we get closer to %12.8 we can set aside some time for the frontend DRI to start reviewing !5974 (closed). It has not been a high priority up to this point.
Thanks Jackie. I think we will need to dedicate time in %12.8 to review the existing MR !5974 (closed). It has been sitting for a while and is a bit large.
@jakeburden lets please touch base about this issue when you are back .
@jmeshell here's some considerations about this issue:
The scope/UI in the SSOT is outdated and does not reflect the latest changes made to the environments variables section. The interaction was refactored in #27480 (closed) and by the end of %12.10 a complete new UI will replace the current one !27699 (merged). This deprectates the design section in this issue #5313 (closed)
The first criteria in the design section is already fixed by the issues linked above/
Done by devopsverify: _Add a table header to the variable list, with column titles: Variable key, Variable value, Protected and Environment scope.
The remaining acceptance criteria in the design section are also outdate, and don't comply with our current design/Pajamas guidelines.
I will also need to check with someone to make !27699 (merged) available behind a feature flag, since I need to test and validate the interaction that was refactored there before I can prototype/scope this issue.
@jakeburden perhaps you can help me here? I need to see the MR above locally. Screen sharing would also help me :)
I'll go ahead and update the contents of this issue (SSOT) and point to the items that are still pending/open UX investigation.
@jmeshell I updated the issue description. Can you please check and complete the sections about the buyer and tier?
@jakeburden can you also have a look and let me know how this looks like from a frontend perspective? I'll ping you for a chat this week so we can align it faster thanks!
Is the asterisk * character required to create wildcards? #5313 (closed) (comment 71893637)
Can users create anything other than an environment wildcard from this UI?
If so, the UI should inform what the user is creating. The call to action option in the dropdown should read as Create new wildcard production*`.
@rayana - I moved this out of cicdactive since this is not ready for development and also we should consider if it should be delivered in %13.0 so I moved it out.
@jmeshell no, as in the problems I identified will be fixed by devopsverify . They already fixed/merged it, and reintroduced the UI pattern I mentioned here:
A recent change !27699 (merged) removed this pattern from the UI. We need to investigate how to reintroduce the searchable dropdown, and why the interaction is no longer available.
That means we should be able to build on top of their code/UI, hopefully with no problems.
Looking back at this, and to answer those questions @rayana and @jmeshell:
Is the asterisk * character required to create wildcards?
Using an * is not required when creating a wildcard environment scope, but it doesn't really function as a wildcard environment scope without one. You can create a wildcard EnvironmentName scope, but that doesn't contain the same qualities that EnvironmentName/* would have, in which the variable would be scoped to any environment that starts with EnvironmentName/ in the latter version.
Wildcards can be used, and the default environment scope is *, which means any jobs will have this variable, not matter if an environment is defined or not.
For example, if the environment scope is production, then only the jobs having the environment production defined would have this specific variable. Wildcards () can be used along with the environment name, therefore if the environment scope is review/ then any jobs with environment names starting with review/ would have that particular variable.
Can users create anything other than an environment wildcard from this UI? If so, the UI should inform what the user is creating. The call to action option in the dropdown should read as Create new wildcard production*`.
Only variables (and file variables), and wildcard environment scopes can be created in this UI. It might add some clarity to add a tooltip or link defining what a wildcard environment scope is in this UI.
Should note that there has been significant updates the the Variables UI since this issue was opened. The UI now looks like this:
@jmeshell @rayana yes, I think since the original problem to solve from this issue is resolved now:
As a user, when I'm managing environment variables with GitLab, I want to be able to see, search, or create a scoped environment in the UI, so that I can quickly define the correct environment for my variable.
So I'll make a separate issue to clarify what creating a wildcard scope does in the UI, and I think we can close this issue?