Merge widget gives ambiguous UI instructions when merge trains are enabled
Summary
When a project has merge trains enabled, the initial state of the merge button widget after a merge request has been created contains contradictory information.
Merge train activated or not?
The primary button here is Start merge train when pipeline succeeds
. Just a couple of pixels further below, the UI states This merge request will start a merge train when pipeline #146704085 succeeds
. I'm not sure whether that now means that I have to press the button to start the merge train, or if that has already been activated.
Black exclamation mark icon
This widget uses the black exclamation mark icon, which is usually used for errors. No other aspects in the UI or text seem like there was an error, so we should either rethink the icon usage here, or explain what the actual error/problem is.
Problem Statement
When a project has merge trains enabled, and there's a merge request that looks ready to merge but still has a pipeline running, users are provided with an action buton Start merge train when pipeline succeeds
. There's no explanation available to understand the consequences of performing the action and the follow up steps. The message is accompanied with a warning icon even though there's no problem with the running pipeline.
Implementation Notes
- Change the ! icon for the pipeline loading.
- Move
This merge request will start a merge train when pipeline # succeeds
from its current position to right under the button. - Change the text for
This merge request will start a merge train when pipeline # succeeds
forThis action will start a merge train when pipeline # succeeds
UX Definition of done
Entry Criteria for `workflow:design`
-
Problem has been validated going though the workflow::problem validation
-
Issue has a clear problem background (why it is prioritised) description -
User stories and acceptance criteria have been created -
Edge cases were considered and described by PM and Product Designer
-
-
UX label is added to the issue
Criteria for UX DoD (exit criteria for `workflow:design`)
-
Cross-team dependencies have been identified and documented, if applicable -
Incremental design approach was applied to split the design problem into small problems and deliverables (UX to work with Engineering) -
Prototype or mock for each user story have been created -
Empty states -
Responsiveness -
Edge cases
-
-
Design proposal was ran and is aligned with engineering team to avoid not feasible solutions and ensure the iteration in our development process -
If changes involve copy, UI text label has been added -
Pajamas: UI Component design have been identified -
Pajamas issue is created (new workflow)
-
-
Marked as Ready for engineering evaluation per user story moved into workflowplanning breakdown & needs weight
Entry Criteria for `workflow::ready for development`
-
Scope has been defined and reviewed with engineering -
User stories have been weighed and are less than 5. See more information on weighting issues -
Create new issues for follow up user stories
**NOTE: **The above criteria is subject to change with iteration on the process.