Improve traffic splitting modal design

[nrfox]

Describe the change

Implements most of the suggested design changes.

Steps to test the PR

1. Deploy kiali hack/run-integration-tests.sh --test-suite backend --setup-only true
2. Go to services list page and click on reviews
3. Right click service icon and click "Request Routing" to open modal

Automation testing

N/A

Issue reference

Follow up from #8938 (comment)

Some things I did not implement:

Update the primary button to 'Create' than Preview.

This modal creates some YAML. All modals that create YAML require you to preview it first. Hitting the "preview" button opens a different modal with all the YAML. Probably the "preview" modal should be updated as well.

Lastly until the issues with the Patternfly Slider have been addressed we need to keep using our custom Slider which has a slightly different styling.

[Joeyyubo]

@nrfox Looks great. Here is some feedback regarding the UX/UI point:

Capitalization: regarding UX writing, all fields and phrases within the modal should follow sentence case rather than title case. For example, it should be "Destination workload" instead of "Destination Workload," and "Show advanced options" instead of "Show AdvancedOptions." This aligns with the [PatternFly Capitalization Guidelines]

Input Group Background: For the % input group, since it provides information without interactivity, the background color should be the default secondary (#F2F2F2). The current color resembles the "disabled" state, which may mislead users into believing the value cannot be modified at all.

Button Label: Using "Preview" as the primary button label is confusing in this context. Since clicking this button completes the traffic distribution configuration and affects the actual system, "Preview" implies a simulation or a non-permanent check. I recommend using a label that clearly indicates the action's finality, such as Create to be aligned with modal header.

Mirror workload: I'd recommend dropping the tooltip—it's redundant since the number input updates in real-time.
Also, should we just remove the actions for Mirrored Workloads? With multiple mirrors, do we really need 'Mirror traffic', or 'lock percentage' , or do those concepts not apply here?"

[Joeyyubo]

Regarding your proposal in patternfly/patternfly-react#12159, I think it is excellent. As I understand it, the current PatternFly component logic keeps the number input in an "editing" state until the user clicks outside the box or hits "Enter," which prevents the slider from updating immediately. The lack of real-time synchronization between the numeric input and the slider is a core usability issue.

I plan to present this solution at the next PF designers' meeting and advocate for incorporating this approach into the official PatternFly guidelines.

[nrfox]

Also, should we just remove the actions for Mirrored Workloads?

The way it currently works you can only mirror one workload at a time and you click mirror workload again to cancel the workload mirroring. The lock icon is disabled in this mode.

[jshaughn]

The way it currently works you can only mirror one workload at a time and you click mirror workload again to cancel the workload mirroring. The lock icon is disabled in this mode.

I don't love that we sort of just throw mirroring in there, but if we remove it we'll lose the ability to set mirroring.

[Joeyyubo]

@nrfox @jshaughn
Considering that Traffic Shifting and Traffic Mirroring follow different mathematical logic, mixing them in the same list is confusing. I propose moving the mirroring configuration to a separate, expandable section. Here is the design and interaction logic:

1. Design Scheme

1. Main List Actions: We already added a "Mirror" action icon to the right side of every workload row in the Traffic Shifting list. This allows users to easily select any workload as a mirror target, regardless of its current traffic weight.
2. Mirror Section & Empty State: The "Traffic Mirroring" section at the bottom will use an Instructional Empty State. The description will explain the value of mirroring and guide the user on how to trigger the action (e.g., "Click the mirror icon above...").

3. Workload Display: Once a workload is selected, the Mirroring section will populate with the chosen workload and a percentage slider.
4. Workload information: Once the Mirroring section is collapsed, the section name will populate with the chosen workload and a percentage slider (e,g. Mirroring traffic (Workload-v2; 33%))

Interaction Logic

1. Selection: Clicking the mirror icon on a workload immediately populates the Mirroring section (expanding it automatically) with that workload as the target.
2. Switching: Since we restrict the configuration to a single mirrored workload, clicking the icon on a different workload simply replaces the current target in the Mirroring section.
3. Tooltips & Operations:

• In Traffic Shifting List: Hovering over the icon displays: "Mirror traffic to this workload".
• In Mirroring Section: Hovering over the action button (e.g., 'Remove' or 'Clear') displays: "Cancel mirroring traffic to this workload".

4. Result: Clicking the remove action clears the workload from the Mirroring section, leaving the section in its empty state.

This approach ensures users can clearly distinguish between the routing destination and the mirrored target, while keeping the configuration intuitive.

[Joeyyubo]

Quick demo video

https://github.com/user-attachments/assets/138b36de-7d61-441d-880b-b57ac2915922
(Apologize for the rendering issues, It bothers me for a long time but I do not know how to fix it)

Interactive prototype: https://www.figma.com/proto/XDFgbelLCdhepNYrYAkdsA/Kiali-PF6-styles-and-patterns?page-id=840%3A12880&node-id=2474-13137&viewport=-1666%2C-314%2C0.24&t=sU6UdPTbjKDPvpEm-1&scaling=min-zoom&content-scaling=fixed&starting-point-node-id=2474%3A13137

Figma design link: https://www.figma.com/design/XDFgbelLCdhepNYrYAkdsA/Kiali-PF6-styles-and-patterns?node-id=2474-8671&t=tBMt7p192DbulFrB-1

[nrfox]

@Joeyyubo alright I implemented the suggested changes for mirroring workloads:

[jshaughn]

Looking good. I know it's not the only screenshot that is out of date on kiali.io, but if you like, you could update the traffic shifting screenshots here and/or here.

[nrfox]

@jshaughn I updated the screenshots: kiali/kiali.io#937

[nrfox]

@Joeyyubo now that we've changed the size of the initial modal, I wonder if we should also change the size of the preview modal to match?

[nrfox]

@Joeyyubo now that we've changed the size of the initial modal, I wonder if we should also change the size of the preview modal to match?

This may affect other modals/actions as well so maybe this should be a follow up. I think we already have an issue to convert the wizards from modals to form pages?

One more thing is that the styling of the icons does not match what is in figma. I kept the styling the way it was to make it consistent with the rest of the UI but if the icon coloring should change then we can create a separate issue for that to change it universally.

[ferhoyos]

I think we already have an issue to convert the wizards from modals to form pages?

There is no a real issue, just a matter of timing. Wizard conversion to form pages is low priority right now.

[Joeyyubo]

@nrfox
During the configuration process, we observed that the modal size fluctuate across stages without clear indicators of a multi-step flow. Since the Traffic shifting configuration logic remains relatively simple and is utilized across multiple pages, I recommend implementing a Modal with Wizard pattern. This preserves the lightweight feel of a modal while providing the necessary visual hierarchy and progress tracking that a standard form might overcomplicate.

Reference: https://docs.google.com/presentation/d/1lc5qttLvb05uW6gVGfdeJIH8MEBvu_K4BN3LUphZCwc/edit?slide=id.g36686817daa_0_0#slide=id.g36686817daa_0_0

[jshaughn]

There is no a real issue, just a matter of timing. Wizard conversion to form pages is low priority right now.

I think we already have an issue to convert the wizards from modals to form pages?

I updated the existing issue, #7823, mentioning the Modal with Wizard pattern. But +1 to the prioritization mentioned by @ferhoyos. As such, I have replaced the backlog label with the help wanted label on that issue.

[jshaughn]

For me, this is good to go!

[nrfox]

I updated the existing issue, #7823, mentioning the Modal with Wizard pattern.

Ok I'll wait then to update this particular modal until we address the broader wizard redesign issue in general and keep this PR as is. Thanks for all the feedback @Joeyyubo!