Redundancy in Menu Items for Project Replicas

[josephaw1022]

I've noticed an issue regarding the user interface when dealing with multiple replicas of a project. Currently, if a project has two replicas, the UI displays a separate menu item for each replica. This can be seen in the screenshots provided:

• First screenshot showing two replicas of a project:
• Second screenshot showing the menu items for each replica:

I propose a more streamlined approach to enhance the user experience. Instead of having multiple menu items for each project replica, it would be more efficient to have a single menu item per project. Upon clicking this item, a specialized view should appear that includes filters for each replica of the project. This would allow users to easily filter out specific replicas and view relevant data on the graphs.

Implementing this change would not only simplify navigation but also improve the clarity and usability of the interface, especially in scenarios where there are multiple replicas of a project.

[tlmii]

I propose a more streamlined approach to enhance the user experience. Instead of having multiple menu items for each project replica, it would be more efficient to have a single menu item per project. Upon clicking this item, a specialized view should appear that includes filters for each replica of the project.

This reads to me like it would take two clicks to view the metrics of a replica, rather than just one as it does now. Can you clarify what I might be missing in that reading of your suggestion?

I will also note that I think we all agree that the handling of replicas and the way we denote them in the UI needs some work. #1184 has some work in it that addresses some of these issues.

[josephaw1022]

I propose a more streamlined approach to enhance the user experience. Instead of having multiple menu items for each project replica, it would be more efficient to have a single menu item per project. Upon clicking this item, a specialized view should appear that includes filters for each replica of the project.

This reads to me like it would take two clicks to view the metrics of a replica, rather than just one as it does now. Can you clarify what I might be missing in that reading of your suggestion?

I will also note that I think we all agree that the handling of replicas and the way we denote them in the UI needs some work. #1184 has some work in it that addresses some of these issues.

@tlmii You're correct in understanding that my suggestion involves a few extra clicks compared to the current system. This approach is somewhat similar to the method used in your PR #987. In that instance, users select a resource type first, then choose from containers, executables, projects, etc. Though this involves more clicks than just using the side nav menu to switch pages, it results in a more organized view and allows for viewing multiple resource types at once.

The idea for viewing project metrics is in line with this. Yes, we could simply switch between different replicas of the app, but consolidating this into a single page with filters allows users to view one, all, or a subset of the replicas for a project. While this means additional clicks, it also brings enhanced organization and the ability to view various metrics concurrently which can save the user time, the same way viewing all of the resources could save a user time (instead of navigating back and forth between projects and containers tab)

I understand that this approach trades the number of clicks for a more organized and flexible viewing experience. I believe that this trade-off is worthwhile, as it ultimately leads to a more efficient and user-friendly interface.

[smitpatel]

See also #567 I think we should look at replica set more holistically now in terms of display on all pages.

[leslierichardson95]

Iteration 1: Gray out the parent and create a pseudo-tree view (ie indenting) of each of the parent's children/replicas for the user to select and view metric data.

If no tree-based dropdown is available, just indent / tab each child

[adamint]

@leslierichardson95 we do not have the ability to create a tree-based dropdown, how much to indent children? Or would you prefer adding some explainer text (possibly in a different color / with icon) aside the name, like in the example below?