Project

General

Profile

Feature #37794

mgr/dashboard: CRUSH map viewer RFE

Added by Ju Lim 9 months ago. Updated 8 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
dashboard/usability
Target version:
Start date:
09/06/2018
Due date:
09/06/2018
% Done:

0%

Source:
Tags:
dashboard, usability, low-hanging-fruit
Backport:
Reviewed:
Affected Versions:
Pull request ID:

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?

crushmap1.png View (37.9 KB) Ju Lim, 01/04/2019 09:33 PM

UX.png View (29 KB) Dan Guo, 01/25/2019 11:09 AM


Related issues

Related to mgr - Feature #35684: mgr/dashboard: CRUSH map viewer/architectural overview Resolved 09/05/2018
Precedes mgr - Feature #25159: mgr/dashboard: Add CRUSH ruleset management to CRUSH viewer New 09/07/2018 09/07/2018

History

#1 Updated by Ju Lim 9 months ago

CRUSH map screenshot

#2 Updated by Ju Lim 9 months ago

  • Related to Feature #35684: mgr/dashboard: CRUSH map viewer/architectural overview added

#3 Updated by Ju Lim 9 months 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

#4 Updated by Ju Lim 9 months ago

  • Follows deleted (Feature #35684: mgr/dashboard: CRUSH map viewer/architectural overview)

#5 Updated by Ju Lim 9 months ago

  • Precedes Feature #25159: mgr/dashboard: Add CRUSH ruleset management to CRUSH viewer added

#6 Updated by Lenz Grimmer 8 months 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.

#7 Updated by Lenz Grimmer 8 months ago

  • Category set to dashboard/usability
  • Tags set to dashboard, usability, low-hanging-fruit

#8 Updated by Dan Guo 8 months ago

Pls assign this issue to me, and I will complete it as soon as possible.

#9 Updated by Lenz Grimmer 8 months 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.

#10 Updated by Dan Guo 8 months 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.

#11 Updated by Dan Guo 8 months ago

  • File deleted (UX.png)

#12 Updated by Dan Guo 8 months ago

#13 Updated by Lenz Grimmer 8 months 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.

#15 Updated by Lenz Grimmer 8 months ago

  • Status changed from New to Need Review
  • Pull request ID set to 26162

#16 Updated by Ju Lim 8 months 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.

#17 Updated by Lenz Grimmer 8 months 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.

#18 Updated by Lenz Grimmer 8 months ago

  • Status changed from Need Review to Resolved
  • Target version set to v14.0.0

Also available in: Atom PDF