Feature #37794
closedmgr/dashboard: CRUSH map viewer RFE
0%
Description
from a UX perspective, I might suggest the following changes:
In looking at the recent CRUSH map viewer that has been introduced into Ceph Dashboard (kudos to the team that added the feature), it would be nice to enhance the user experience (UX) of the CRUSH map viewer. The following are some UX suggestions:
- It would be nice if the selection used a cyan/blue selection vs. underline to be consistent with the rest of the application.
- If there are a lot of OSDs in a crush map bucket, e.g. ceph(host) in this example, when user scrolls it will be hard for user to know which crush map bucket the OSD belongs to. It would be good to have some way to outline the selection, i.e. ceph(host) and it's children, when it's expanded to know what's in the bucket itself.
- In the table, it would be nice if the status, e.g. "up" had the same visualization as the tree on the left (to be consistent with other table views showing status).
- In the table on the right, is it possible for the name, id, and type to be higher up in the table? It just seems odd not to see property/config info of the selected item towards the top of the table.
- Are there plans to show the crush rulesets in the future?
Files
Updated by Ju Lim over 5 years ago
- Related to Feature #35684: mgr/dashboard: CRUSH map viewer/architectural overview added
Updated by Ju Lim over 5 years ago
- Due date set to 09/06/2018
- Start date changed from 01/04/2019 to 09/06/2018
- Follows Feature #35684: mgr/dashboard: CRUSH map viewer/architectural overview added
Updated by Ju Lim over 5 years ago
- Follows deleted (Feature #35684: mgr/dashboard: CRUSH map viewer/architectural overview)
Updated by Ju Lim over 5 years ago
- Precedes Feature #25159: mgr/dashboard: Add CRUSH ruleset management to CRUSH viewer added
Updated by Lenz Grimmer over 5 years ago
Hi Ju,
thanks a lot for the detailed suggestions, much appreciated.
Ju Lim wrote:
from a UX perspective, I might suggest the following changes:
In looking at the recent CRUSH map viewer that has been introduced into Ceph Dashboard (kudos to the team that added the feature), it would be nice to enhance the user experience (UX) of the CRUSH map viewer.
Yes, thanks to Dan Guo for contributing this initial implementation! I agree that it can be improved.
The following are some UX suggestions:
- It would be nice if the selection used a cyan/blue selection vs. underline to be consistent with the rest of the application.
Agreed!
- If there are a lot of OSDs in a crush map bucket, e.g. ceph(host) in this example, when user scrolls it will be hard for user to know which crush map bucket the OSD belongs to. It would be good to have some way to outline the selection, i.e. ceph(host) and it's children, when it's expanded to know what's in the bucket itself.
Good idea. Is there any existing UI element that could be utilized here?
- In the table, it would be nice if the status, e.g. "up" had the same visualization as the tree on the left (to be consistent with other table views showing status).
Agreed.
- In the table on the right, is it possible for the name, id, and type to be higher up in the table? It just seems odd not to see property/config info of the selected item towards the top of the table.
Good point, this should probably be above the table or as a table heading, in the same format as it's written in the tree view "<name>.<id> (<type>)"
- Are there plans to show the crush rulesets in the future?
There is a desire to add this (see #25159), but no concrete plans yet.
Updated by Lenz Grimmer over 5 years ago
- Category set to 152
- Tags set to dashboard, usability, low-hanging-fruit
Updated by Dan Guo over 5 years ago
Pls assign this issue to me, and I will complete it as soon as possible.
Updated by Lenz Grimmer over 5 years ago
- Assignee set to Dan Guo
Dan Guo wrote:
Pls assign this issue to me, and I will complete it as soon as possible.
Great! Done. Thanks for your offer to help.
Updated by Dan Guo over 5 years ago
- File UX.png added
- Assignee deleted (
Dan Guo)
Ju Lim wrote:
- It would be nice if the selection used a cyan/blue selection vs. underline to be consistent with the rest of the application.
complete, Pls see attach and give me advice.
- If there are a lot of OSDs in a crush map bucket, e.g. ceph(host) in this example, when user scrolls it will be hard for user to know which crush map bucket the OSD belongs to. It would be good to have some way to outline the selection, i.e. ceph(host) and it's children, when it's expanded to know what's in the bucket itself.
Sorry for I have not found a good method to solve this problem after I investigated 'ng2-tree'. I still trying on it. Maybe someone has a good idea and I am very happy to hear it.
- In the table, it would be nice if the status, e.g. "up" had the same visualization as the tree on the left (to be consistent with other table views showing status).
Done, Pls check the attach and give me advice.
- In the table on the right, is it possible for the name, id, and type to be higher up in the table? It just seems odd not to see property/config info of the selected item towards the top of the table.
As I knew, all the table which data has the format of key-value have been sorted by the 'key' before rendered. So, I just add a 'legend' title above the metadata table, like did in the monitor table page.
Updated by Lenz Grimmer about 5 years ago
- Assignee set to Dan Guo
Hi Dan, thank you so much for looking into this, much appreciated.
Dan Guo wrote:
- It would be nice if the selection used a cyan/blue selection vs. underline to be consistent with the rest of the application.
complete, Pls see attach and give me advice.
Looks good to me!
- If there are a lot of OSDs in a crush map bucket, e.g. ceph(host) in this example, when user scrolls it will be hard for user to know which crush map bucket the OSD belongs to. It would be good to have some way to outline the selection, i.e. ceph(host) and it's children, when it's expanded to know what's in the bucket itself.
Sorry for I have not found a good method to solve this problem after I investigated 'ng2-tree'. I still trying on it. Maybe someone has a good idea and I am very happy to hear it.
If there's no immediate solution, let's tackle this aspect in a separate PR.
- In the table, it would be nice if the status, e.g. "up" had the same visualization as the tree on the left (to be consistent with other table views showing status).
Done, Pls check the attach and give me advice.
I actually like this better than having it in the data table, but I would suggest to put the status behind the name, not in front of it - what do others think?
- In the table on the right, is it possible for the name, id, and type to be higher up in the table? It just seems odd not to see property/config info of the selected item towards the top of the table.
As I knew, all the table which data has the format of key-value have been sorted by the 'key' before rendered. So, I just add a 'legend' title above the metadata table, like did in the monitor table page.
Looks good. Would it be possible to filter out the redundant rows from the table then? Just to reduce the clutter and to avoid displaying duplicate information.
Updated by Dan Guo about 5 years ago
Updated by Lenz Grimmer about 5 years ago
- Status changed from New to Fix Under Review
- Pull request ID set to 26162
Updated by Ju Lim about 5 years ago
The changes look good -- thanks Dan Guo for making them!
+1 on tackling the outline the selection [i.e. ceph(host) and it's children, when it's expanded to know what's in the bucket itself] as a separate PR.
The status should come before the object name and not after the name. It's a more common pattern/practice in management software.
+1 on filtering out redundant rows/text in the table.
Updated by Lenz Grimmer about 5 years ago
Ju Lim wrote:
The changes look good -- thanks Dan Guo for making them!
Agreed, thank you!
The status should come before the object name and not after the name. It's a more common pattern/practice in management software.
Interesting, I wasn't aware of that - somehow I assumed that it would be more logical to first find the object that I'm interested in before I know it's status - I guess it depends on which information is more important in this scope. In this view, it's more about the structure ("which OSD is located where) and less about the OSDs status (which can be obtained from the dedicated OSD page). But if that's a more common approach, let's stick to showing the status before the object name.
Updated by Lenz Grimmer about 5 years ago
- Status changed from Fix Under Review to Resolved
- Target version set to v14.0.0
Updated by Ernesto Puerta about 3 years ago
- Project changed from mgr to Dashboard
- Category changed from 152 to UX