Project

General

Profile

Cleanup #37337

mgr/dashboard: Consistent labeling for buttons: 'Edit pool' (pool) vs. 'Update RBD' (images) vs. 'Update' (RGW) vs. 'Submit' (Cluster wide flags) ...

Added by Ernesto Puerta 5 months ago. Updated 8 days ago.

Status:
Resolved
Priority:
Low
Category:
dashboard/general
Target version:
Start date:
11/20/2018
Due date:
% Done:

0%

Tags:
usability
Backport:
nautilus
Reviewed:
Affected Versions:
Pull request ID:

Description

Buttons for saving Update forms are labelled differently:
  • 'Edit pool' in Pool's editor
  • 'Update RBD' in Image's editor
  • Just 'Update' in RGW users & buckets
  • 'Submit' in OSD cluster-wide flags.
For creation, it kind of happens the same:
  • 'Create Pool/Create RBD' for Pools&Images.
  • Just 'Add' for RGW.
While nothing really burning, I'd try to get a shared label for these. That would also make i18n easier. My bet is just either 'Add/Update' or just 'Submit' for both Add/Edit:
  • 'Edit' is redundant and a bit confusing, since you're already 'editing' the thing.
  • Less is more: 'Update {{whatever}}' does not really add extra info, as the whole UI context tells you what you're updating. And this way you avoid naming inconsistencies like the 'Update RBD' when you are 'Editing an Image'.
  • 'Update' vs. 'Submit': Submit sounds more vintage (web 1.0, aka 'submit a form'), but 'Update' forces you to keep 'Add' and 'Update' (nothing terrible though).

Any thoughts?

current.png View - as per proposed in original (16.6 KB) Ernesto Puerta, 02/26/2019 08:44 PM

suggestion.png View - new suggestion (13.8 KB) Ernesto Puerta, 02/26/2019 08:44 PM


Related issues

Copied to mgr - Backport #39003: nautilus: mgr/dashboard: Consistent labeling for buttons: 'Edit pool' (pool) vs. 'Update RBD' (images) vs. 'Update' (RGW) vs. 'Submit' (Cluster wide flags) ... Resolved

History

#1 Updated by Ernesto Puerta 5 months ago

  • Subject changed from Consistent labeling for buttons: 'Edit pool' (pool) vs. 'Update RBD' (images) vs. 'Update' (RGW) vs. 'Submit' (Cluster wide flags) ... to mgr/dashboard: Consistent labeling for buttons: 'Edit pool' (pool) vs. 'Update RBD' (images) vs. 'Update' (RGW) vs. 'Submit' (Cluster wide flags) ...

#2 Updated by Ernesto Puerta 5 months ago

I briefly went through both EOS and Patternfly projects for guidelines:
  • in EOS I didn't find any direct suggestion.
  • in PF they're commonly using 'Save' and 'Cancel' (instead of our 'Edit'/'Update'/'Submit' and 'Back').

#3 Updated by Lenz Grimmer 3 months ago

Per our discussion, we'll use "Action + Object", e.g. "Delete RBD", "Create Pool".
Use "Cancel" for aborting an operation instead of "Back" or something else.

Follow https://www.patternfly.org/styles/terminology-and-wording/ for "Create" vs. "Add"

Examples: Create OSD, Create Pool, Create RBD Image but Add User, Add Group, Add Permission

#4 Updated by Ernesto Puerta 2 months ago

  • Status changed from New to In Progress

#5 Updated by Ernesto Puerta about 2 months ago

Most naming inconsistencies come from the high redundancy in text items, that needs to be kept manually. There are enough textual/UI hints for the user to become aware of their current actions and outcomes: URL, breadcrumbs, frame title, button label, task title.

My suggestion would be to:
- Keep/use CRUD-like naming for URLs: <resource>/{create,edit,delete,clone,copy}
- Keep breadcrumbs, as they help understand the user where they are within the website navigation.
- Keep Form Titles in Headline capitalization ("Action Resource", or even simpler: "Resource")
- Simplify buttons: only "Save/Cancel", without resource/item mentioning (no button labeled "Add Image", but just "Save").

as per proposed in original new suggestion

#6 Updated by Lenz Grimmer about 2 months ago

Hi Ernesto,

Ernesto Puerta wrote:

Most naming inconsistencies come from the high redundancy in text items, that needs to be kept manually. There are enough textual/UI hints for the user to become aware of their current actions and outcomes: URL, breadcrumbs, frame title, button label, task title.

My suggestion would be to:
- Keep/use CRUD-like naming for URLs: <resource>/{create,edit,delete,clone,copy}
- Keep breadcrumbs, as they help understand the user where they are within the website navigation.
- Keep Form Titles in Headline capitalization ("Action Resource", or even simpler: "Resource")
- Simplify buttons: only "Save/Cancel", without resource/item mentioning (no button labeled "Add Image", but just "Save").

new suggestion

I would be very much in favor of adapting this, thank you for this proposal! I'm all for simplicity, so the second suggestion would be my favorite. Thanks!

#7 Updated by Lenz Grimmer about 2 months ago

  • Tags set to usability

#8 Updated by Ernesto Puerta about 2 months ago

Thanks, Lenz. I'll update my PR to get it aligned with the former proposal. I've also asked Ju to have a look at this for her views on it.

#9 Updated by Ju Lim about 2 months ago

First off thanks for bringing this up. I've to admit it was confusing to me as well when I first started looking at Ceph Dashboard, and I'm glad we've folks willing and able to take this one up!

  • +1 Keep/use CRUD-like naming for URLs: <resource>/{create,edit,delete,clone,copy}
  • +1 Keep breadcrumbs, as they help understand the user where they are within the website navigation, and it should say “Action Resource”.
  • Have Form Titles in with appropriate capitalization/camelcase, i.e. “Action + Object” (e.g. Create Bucket) so it’s clear to user what he/she is doing -- especially if they walk away from their browser (a lot of context-switching happens in a regular day) and returns back to the Ceph Dashboard window/tab in the browser.
  • Buttons should be ““Action + Object” (e.g. Create Bucket) or “Cancel” (which replaces “Back” as it’s confusing when it’s really aborting/cancelling the action). The reason I suggest not using “Save” or “Submit” is they are not clear to the user what they are doing. From past experience and usability testing especially in wizards with many steps, “Next” and “Save” was not clear whether data is being persisted or not, whether it was saving a state or actually creating something, etc. It's probably less a concern since we don't yet have any wizards in Ceph Dashboard yet.

#10 Updated by Ernesto Puerta about 2 months ago

Thanks a lot for the feedback, Ju!

So, just to clarify:
  • On breadcrumbs, you suggest moving from, let's say:
    1. "Object GW >> Bucket >> Create" (current) to
    2. "Object GW >> Create Bucket" or
    3. "Object GW >> Bucket >> Create Bucket"?

If everyone else is happy with the suggestions I'll make the changes (not many) to bring the missing bits in.

#11 Updated by Ju Lim about 1 month ago

Regarding breadcrumbs, both #2 or #3 work, though I'd suggest going with #3 ("Object GW >> Bucket >> Create Bucket").

  • On breadcrumbs, you suggest moving from, let's say:
    1. "Object GW >> Bucket >> Create" (current) to
    2. "Object GW >> Create Bucket" or
    3. "Object GW >> Bucket >> Create Bucket"?

#12 Updated by Lenz Grimmer about 1 month ago

Ju Lim wrote:

Regarding breadcrumbs, both #2 or #3 work, though I'd suggest going with #3 ("Object GW >> Bucket >> Create Bucket").

  • On breadcrumbs, you suggest moving from, let's say:
    1. "Object GW >> Bucket >> Create" (current) to
    2. "Object GW >> Create Bucket" or
    3. "Object GW >> Bucket >> Create Bucket"?

Thanks for the suggestions! Option#3 sounds good to me as well.

#13 Updated by Ernesto Puerta 25 days ago

  • Status changed from In Progress to Need Review

#14 Updated by Lenz Grimmer 25 days ago

  • Target version changed from v14.0.0 to v15.0.0
  • Backport set to nautilus
  • Pull request ID set to 26572

#15 Updated by Ernesto Puerta 23 days ago

  • Status changed from Need Review to Pending Backport

#16 Updated by Nathan Cutler 23 days ago

  • Copied to Backport #39003: nautilus: mgr/dashboard: Consistent labeling for buttons: 'Edit pool' (pool) vs. 'Update RBD' (images) vs. 'Update' (RGW) vs. 'Submit' (Cluster wide flags) ... added

#17 Updated by Ricardo Marques 8 days ago

  • Status changed from Pending Backport to Resolved

Also available in: Atom PDF