Beautifying of our UI 16.8 - Variables

Who'll take part and when?

Milestone 16.8 (18th Dec 2023 to 17th Jan 2024)

Frontend: @mgandres

UX: @veethika , capacity dedicated 50%

Backend(?): yet to confirm

What would we look at?

Variables in GitLab have been in a workable condition for sometime now. That mean we are not providing the optimal experience to our users and they are having to come up with workarounds to leverage the feature in a way that suits their workflow.

Example of custom tool | Highlights from recent research - scans to catch variable leaks

The new concerns that still require a lot of coordination are:

1. Variable hierarchy representation
2. Easier workflow for creating multiple values for same variables for different environments
3. Relook at the overall validations

Confirmed issues

Issue	Design ready?	MR
Change the alignment of buttons in the variables drawer to match guidelines~~	✅	!141455 (merged)
Make the add variable form appear inline	✅	❌
Improve the experience for inputting value for a file type variable	✅	!140837 (merged)
Drawer closes after adding individual variables on the CI/CD setting page	✅	!143901 (merged)
Frontend: Add optional description field for Project and Group CI variables	✅	!140549 (merged), !140547 (merged)
Frontend: Add a helpful validation message when variable value doesn't meet required minimum characters	--	!135823 (merged)
Improve help text for key field while creating a variable	--	!137370 (merged)

How would it impact business?

To adopt GitLab within the organization, teams are having to spend a lot of time of custom solutions for managing variables across hierarchy. A good solution straight out of the box will mean lesser hesitation and effort towards adoption. making GitLab CI an even more attractive option industrywide.

What would this pairing/partnership look like?

• Self-Directed: There are no restrictions on where in the product the pair can make improvements. The goal is to empower the pair to focus on usability improvements that they personally want to see fixed in a product that they use themselves almost every day.
• Area focused pairing and prioritization: The Product Designer and Engineer pair do not need to be from the same stage group. This is a voluntary initiative.
  • The Product Designer and Engineer(s) will inform their stage group team of their involvement in the initiative, so that they can make time for it during milestone planning.
• Work in MRs, not issues: Both the Product Designer and the Engineer should work directly in MRs to make changes. For the Product Designer, these MRs will likely be focused on less complex usability issues that the pair identifies, such as documentation, minor UI polish, or UI text changes.