Frontend: Change the pattern and sequence of sub-tasks for adding and editing a variable

Feedback issue: #428807 (closed)

Release notes

Problem to solve

The modal for adding a new variable does not have a logical task-flow associated with it. The fields are placed at the top so users fill them out first, then comes the security settings like protected, masked, etc.. After selecting those, new validation kicks in for the key and value fields. So what was valid before, is invalid now!

To make it task-flow more intuitive, the order of elements and actions need to be completely changed.

Supporting insight

Developer would like an easier way to add multiple variables

Intended users

Anyone with a maintainer permission to be able to add a variable.

User experience goal

The taskflow shouldn't make users revisit the tasks they've already accomplished and keep going back and forth.

Proposal

• Instead of a modal, use a drawer. Its a better choice as it allows users to simultaneously see the variables being added to the list. Even while editing, the feedback is real time.
• Bring the type, environment and security options to the top. Remove sub-header flags.
• Change the variant of Add variable button to default so we don't have 2 primary buttons visible on the screen.

Implementation Plan

This issue will focus on setting up the feature flag and main drawer component with the fields (no validation/form submission yet). The drawer should be able to open/close as expected when the FF is enabled and the user tries to edit or create a CI variable.

In follow-up MRs, we can work on validating the fields and making sure events are emitted correctly.

We can iterate over this issue like so:

Iteration	MR
Setup drawer with feature flag	You are here!
Add form validations	#421262 (closed)
Implement actions	#421263 (closed)
Feature flag rollout	#418005 (closed)

Further details

Permissions and Security

Documentation

Availability & Testing

Available Tier

Feature Usage Metrics

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

What is the competitive advantage or differentiation for this feature?

Links / references

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

added CI variables Category:Secrets Management GitLab Free GitLab Premium GitLab Ultimate UX direction documentation grouppipeline security severity3 typefeature + 1 deleted label

changed the description

added devopsverify sectionops labels

added to epic &10506 (closed)

added 1 design

started a discussion on add-variable-workflow.png

started a discussion on add-variable-workflow.png

updated 1 design

started a discussion on add-variable-workflow.png

marked this issue as blocking #410220 (closed)

marked this issue as blocking #365934 (closed)

mentioned in issue #365934 (closed)

mentioned in issue #410220 (closed)

added workflowdesign label and removed devopsverify sectionops labels

added devopsverify sectionops labels

added frontend label

@mgandres @mfluharty @morefice another one of UI structural changes, but FE only. I started to work on validations but the experience was very strange because the option at the bottom of the modal changed the validations above. making users fill out details twice. So I proposed flipping the order first.

I made sure I'm only proposing FE changes in this proposal.

@veethika Added my comments in the design. The modal was getting too crowded anyway, so I like this new layout. The point about validations also make sense to me

@veethika

Interesting proposal, I like where this is going great work

Added my thoughts on the design as well.

@jocelynjane @veethika

This can be a quick win and could be achievable within 1 milestone.

Thoughts about adding this item as part of our OKR for Q2?

cc @mgandres

Thoughts about adding this item as part of our OKR for Q2?

I absolutely agree

That sounds like a good plan to me. It's good to also have some frontend-only issues that are not dependent on backend work.

cc @mfluharty

This will probably be a frontend-weight3 btw. I mentioned that this is achievable in one milestone and it's a frontend-only change, but I think the engineer who will be working on this will be focusing on this implementation for most if not the whole milestone. There are multiple existing form validations here in the modal that we should make sure is maintained in the drawer. Since this is a new component, we might also want to roll this out under a feature flag.

cc @morefice @jocelynjane

There are still some outstanding questions in the design so I'll keep the workflowplanning breakdown label for now, but I don't think it would affect the weight.

@mgandres

Thanks for looking into this.

Any ideas how we could split this up in smaller chunks so we can better iterate on this?

cc @jocelynjane

@morefice We can perhaps create multiple MRs like this:

1. Set up the feature flag and main drawer component with the fields (no validation/form submission yet). The drawer should be able to open/close as expected when the FF is enabled and the user tries to edit or create a CI variable.
2. Validate the fields and make sure events are emitted correctly. If the engineer is inclined, they can further break this down into separate MRs. This part is chunky only because there are a lot of fields here with their own validation rules. These are the events the modal needs to emit:
   • Adding a variable
   • Editing a variable
   • Deleting a variable
   • Search environment scope (bubbled up from the component for environment scope dropdown)
3. Feature flag rollout + cleanup.

I've added this to the description of the issue, as well as some additional technical notes for context.

@jocelynjane @mgandres

Based on the proposed plan from above, thoughts about splitting this issue in 3 issues?

1. Introduce drawer behind feature flag for adding/editing variable
2. Add validations to drawer
3. Release the feature

Or we can use the implementation table that grouppipeline authoring is doing?

For me, the breakdown is more on the implementation side of things but they all still make up one MVC. I would prefer to just have one issue for it (with maybe multiple MRs that are all linked here, like with an implementation tavle) so that all related discussion and updates would be in one place.

@mgandres

Works for me I agree

@morefice @mgandres I'm fine with keeping it all under one issue, as long as we can keep it to the single milestone implementation (would prefer to not have carryover work tasks; makes planning more difficult.).

Based on our retrospective, I think this is an issue that is a good candidate for breaking up into smaller issues. I don't think I can finish this in 16.3, so the work for this will carry over.

I'm going to make two issues after this: one for adding validation to the drawer (in progress, there's a lot of them and I might actually go through the docs and check if they're updated as well ) and one for implementing actions like create/edit/delete for variables.

@veethika @shampton @jocelynjane WDYT? Also, if we're breaking this issue down into smaller pieces, do you want to keep this one open or should I close it? The only thing merged into the codebase right now is that we've added the drawer under a feature flag with the new layout, but it doesn't really do anything right now.

In retrospect, the whole drawer might have been a frontend-weight4 after all.

@mgandres I'm good with breaking this issue down into smaller pieces, and your proposal for two follow-up issues sounds good to me.

If we do follow that route, let's refine this issue to say what we accomplished and close it.

Yes - agree this should be broken into smaller pieces @mgandres @shampton.

Alternatively, I suggest we make this an epic and have 3 issues that accurately capture the breakdown of work (including the drawer with the new layout, already done).

@shampton @jocelynjane I've created two new issues in #421262 (closed) and #421263 (closed). I also added the implementation table in the description of these issues.

The description for this issue is updated to reflect the new plan. I think we can close this one now and move on to #421262 (closed).

In retrospect, the whole drawer might have been a frontend-weight4 after all.

Thanks for highlighting this @mgandres I'll also proactively make suggestions/solicit feedback on how to break a proposal into multiple issues if required.

changed title from Reverse the order of the element in add variable modal to Reverse the order of items in add variable modal

changed the description

updated 1 design

mentioned in epic &10506 (closed)

changed the description

changed title from {-Reverse the order of items in add-} variable{- modal-} to Change the pattern and sequence of sub-tasks for adding and editing a variable

started a discussion on add-variable-workflow.png

updated 1 design

started a discussion on add-variable-workflow.png

updated 1 design

updated 1 design

changed title from Change the pattern and sequence of sub-tasks for adding and editing a variable to Frontend: Change the pattern and sequence of sub-tasks for adding and editing a variable

added workflowplanning breakdown label and removed workflowdesign label

changed milestone to %16.2

added quick win label

changed the description

mentioned in issue #378938 (closed)

added frontend-weight3 label

set weight to 3

marked this issue as blocking #378938 (closed)

changed the description

mentioned in merge request !122131 (merged)

mentioned in issue gitlab-com/Product#6195 (closed)

added workflowready for development label and removed workflowplanning breakdown label

added sectionci label and removed sectionops label

marked this issue as blocking #367220 (closed)

marked this issue as blocking #367222 (closed)

marked this issue as blocking #367223

added Deliverable VerifyP1 labels

Setting health status to on track as the milestone has just begun.

Issue participants are welcome to override this by setting the health status to another value.

changed health status to on track

@veethika I think this is a good release post candidate - your thoughts?

@jocelynjane yes this can be. There's no major change in experience at the moment but we should highlight that this forms the foundation for upcoming changes.

assigned to @mgandres

mentioned in issue #408413

This issue is scheduled for completion in this milestone but is not yet in development. Changing health status to 'needs attention'.

Issue participants are welcome to override this by setting the health status to another value.

changed health status to needs attention

removed GitLab Premium label

removed GitLab Ultimate label

added release post itemsecondary label

added release post itemin review label and removed release post itemsecondary label

mentioned in merge request gitlab-com/www-gitlab-com!126865 (closed)

changed milestone to %16.3

changed health status to on track

added workflowin dev label and removed workflowready for development label

mentioned in merge request !126197 (merged)

mentioned in issue gitlab-com/Product#11409 (closed)

mentioned in issue #418005 (closed)

mentioned in issue #421262 (closed)

mentioned in issue #421263 (closed)

changed the description

added workflowfeature-flagged label and removed workflowin dev label

closed

mentioned in issue #422562

mentioned in issue #422563

mentioned in issue #422564

mentioned in merge request gitlab-org/gitlab-services/design.gitlab.com!3497 (closed)

mentioned in issue #367222 (closed)

removed the relation with #367223

removed the relation with #367222 (closed)

removed the relation with #367220 (closed)

removed the relation with #378938 (closed)

removed the relation with #365934 (closed)

removed the relation with #410220 (closed)

mentioned in merge request gitlab-org/gitlab-services/design.gitlab.com!3531 (merged)

@mgandres where exactly did we land on this issue? I can't figure out the final status here. Thanks!

@jocelynjane We broke this down into several issues, listed in the Implementation Plan in the description.

The latest status was in this comment. We closed this issue to work on the others

Excellent I missed the implementation plan when scrolling too quickly.

Since we broke this down in different steps during implementation, all the issues are closed except for the rollout issue, so I'm not sure which "feature issue" to notify

But just to be sure, QA issues have been fixed and I have verified that this works on staging and production, so I will be starting the feature flag rollout today. Please refer to the rollout issue (#418005 (closed)) for further updates.

cc @shampton @jocelynjane

Hey team, @jocelynjane @veethika,

I just configured CI variables for the first time since this landed, and I think the UX is somewhat unfortunate. This is the first drawer for settings that I see, so it came somewhat as a surprise. It's sure better than the modal before, but together with the modal for deploy keys and the inline editing for protected branches and token access, that adds up to three different ways to edit settings on that CI settings page.

Wouldn't an inline edit also have had the same benefit of showing the variables in the list as they are added without introducing a new way to interact with settings?

Wouldn't an inline edit also have had the same benefit of showing the variables in the list as they are added without introducing a new way to interact with settings?

@mbruemmer we looked at a set of problems that users were facing previously while adding variables to the list. The modal lead to lack of real time feedback on what was being added or not to the list. If there were errors, they appeared after closing the modal. And for every new variable to be added, the modal had to be reopened. Wasn't a great experience.

Secondly, we didn't go for inline edit because there are a lot of fields and check boxes that we cannot take away. So an entire form would have to be put together. This again would push down the table for a usual screen size repeating the same problems again.

Can you share more about what didn't work well for you besides lack of consistency with other ways of editing available on settings page?

@mgandres @jocelynjane may be we should open a feedback issue.

@veethika Thank you for the detailed response. I think your reasoning is sound and I didn't have general problems with the interaction. I was surprised, as it's a new pattern, but it isn't necessarily bad.

The only issue really is that all those different interactions are causing me to have to refocus for each individual setting I'm editing, as I don't know what to expect. It causes more cognitive load than necessary and having it consistent would just be a much better experience.

One minor point that also applies for the other settings: The page is (by its nature) incredibly busy. If I wasn't familiar, I would have some trouble finding the "Add variable" button opening the drawer (similar for trigger token, protected environments and others on that page). Maybe that could be highlighted in a different color?

One minor point that also applies for the other settings: The page is (by its nature) incredibly busy. If I wasn't familiar, I would have some trouble finding the "Add variable" button opening the drawer (similar for trigger token, protected environments and others on that page). Maybe that could be highlighted in a different color

Thanks @mbruemmer , I'll take a look at this and will also share this feedback with our UX papercuts team to see if we can collaborate with them to improve this experience. cc @annabeldunstone

@veethika @annabeldunstone - feedback issue has been created #428807 (closed) and linked at the top of this issue. Is there anything we can do to proactively gather feedback? Thanks!

@jocelynjane for the changes to build feature, Jackie and I added the feedback issue to the release post.

Thanks @veethika - will do the same here

@veethika Sorry for the delay; is there something I can help with here?

I would have some trouble finding the "Add variable" button opening the drawer (similar for trigger token, protected environments and others on that page). Maybe that could be highlighted in a different color?

@annabeldunstone I need some papercut help with the placement of the Add variable button. Since we use a drawer now, this hides behind it. When we had started to work on the drawer, the button used to be placed differently.

Also there's this feedback that it's less conspicuous compared to before. Since the button treatment is standard across all settings sections, I'd defer it to you to make any decision on thatbased on feedback from other sources.

Since we use a drawer now, this hides behind it.

@veethika Do you mean when you click Add variable, the button is hidden behind the open drawer? Is that an issue, or should you be able to click it multiple times, even when the form/drawer is open?

Also there's this feedback that it's less conspicuous compared to before

Is there more feedback, other than what @mbruemmer wrote? (I see that there's a feedback issue but it doesn't look like anyone has posted yet)

If the drawer is the issue, perhaps the form could appear inline, like Pipeline trigger tokens below

If the drawer is the issue, perhaps the form could appear inline, like Pipeline trigger tokens below

@annabeldunstone that's something I'm considering too. The only apprehension I have is the form can run very long. I'll create an issue and explore how we can fit it in there.

Is there more feedback, other than what @mbruemmer wrote? (I see that there's a feedback issue but it doesn't look like anyone has posted yet)

Nothing that I came across, that's why I deferred it to you. We do have a feedback issue open so i'll just keep an eye out.

Edit: issue: #429462 (closed)

mentioned in issue #428807 (closed)