Needs work
Project:
Drupal core
Version:
main
Component:
user interface text
Priority:
Minor
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
7 Jun 2023 at 02:29 UTC
Updated:
9 Nov 2023 at 11:12 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #3
arjak-mondal commentedThe Block type description field label is already updated. Screenshot attached. Changing the description field label only for the Add menu Page.
Comment #4
chris matthews commentedComment #5
istryker commentedI can confirm 2 things are fixed.
grep -rnw ./ 'Block description'and got no resultsComment #7
lauriiiI'm wondering if "Administrative summary" would be a better label for these fields because it describes what the description is used for. It looks like "Add menu" description was labelled as "Description" in the past, and was intentionally changed in #1926692: Menu description is misleading to allow for multiline input.
Comment #8
smustgrave commentedI can agree with that I think.
Comment #11
hebl commentedHey guys, I wasn't sure whether the changes to "Administrative summary" was agreed for all of the fields in the table in the original description. Or whether it was just for the two Menu and custom block.
I've added an MR which addresses the Custom block.
Happy to take another look if we want to change for all of the rows in the table. Cheers!
Comment #12
smustgrave commentedThanks for working on this. Can you add your changes to the exciting MR though please
Comment #14
Ajeet Tiwari commentedKindly review the patch.
Comment #15
smustgrave commentedThis issue was started in an MR and should continue there per policy.
Comment #16
hebl commented@smustgrove, Unless I'm mistaken, it looks to me like @bharath-kondeti has added a new commit to the original MR, which addresses the issue: Merge request !4128.
Comment #17
smustgrave commentedComment was for #14
But MR 4128 has a failure.
Comment #18
hebl commentedUnderstood, apologies. Don't have much experience with tests and failures but will take a look.
Comment #19
smustgrave commentedThat one is odd will admit.
Comment #20
hebl commentedHey @smustgrave,
Ran the tests again and they’ve passed this time.
Is this ready for review now?
Comment #21
smustgrave commentedOdd.
But should of also noted the MR and issue summary proposed solution do not match.
Comment #22
hebl commented@smustgrave,
Didn't comments #7 and #8 update the requirements of the task to something different to the issue summary?
Comment #23
smustgrave commentedif that's the case the issue summary needs to be updated.
Comment #24
atul4drupal commentedI here do not agree with the direction this thread has taken from #7.
I understand and support the IS as it was originally created.
The issue refered at #7 has targeted the multi-line nature of description field and as obvious going through that thread it clearly seems that they had discussed about reducing length of description field to change it to textfield supporting single line description, however the change in label was taken as granted without any discussion/consideration. This thread wanted to rightly streamline the labelling for description field.
10 years ago this got missed and I agree with Chris Matthews on this that the field label should be consistent, unless we have a strong case deviating from it.
Reasons to have consistency:
1) Go To
1.1) "admin/structure/types/add"
Notice description field label and the help text shown below the field.
1.2) "admin/structure/taxonomy/add"
Notice the description field label.
1.3) "admin/structure/menu/add"
Notice the description field label it simply stands out as "Administrative summary" why this in consistency.
If we were to indicate that this description will appear only at administrative page then for that clarification we have the provision to add
help text for the field, why change the field label altogether that too inconsistently.
2) Any mature application/software professes consistency and standardisation and I believe that this issue rightly progresses towards that.
Likewise at "block/add" page for description field why to have "Block Description" label when its so obvious, you are already at "Add content block" page just having "description" label is enough, for further clarification we may always add the help text.
On the contrary when you are at "admin/structure/block-content/add" the label for description field is just "description".
At "admin/structure/comment/types/add" also we have description label.
I think having consistent label is good and any meta about the field if needed can be provided as help text.
Comment #25
atul4drupal commentedComment #26
flusteredlondon commentedI'm at Drupalcon Lille, and working on this today..
Comment #27
flusteredlondon commentedChecked:
Both are updated.
Comment #29
lauriiiI don't agree that the label was changed in #1926692: Menu description is misleading to allow for multiline input without any consideration given that the issue started with the statement that "Description" label doesn't describe what it's used for. I'm not feeling too strongly about the label itself. However, if we want to revert the label, we need to come up with an alternative solution to address #1926692: Menu description is misleading to allow for multiline input.
Comment #30
smustgrave commentedSeems like a still NW issue.
Comment #31
rkollerWe discussed this issue at #3397066: Drupal Usability Meeting 2023-11-03. That issue will have a link to a recording of the meeting.
For the record, the attendees at today's usability meeting were @AaronMcHale, @anmolgoyal74, @benjifisher, @ckrina, @rkoller, and @simohell.
If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.
In general, the group was in line with the gist of what this issue is about: consistency is a good thing. There was some discussion to iterate in a direction the term
Administrative summaryheaded. To convey that the description is only used in the administrative interface. But there is a potential problem with the expectations a user might have with the termSummary. The term is usually used in the context of summarizing longer texts (for example "text formatted long with summary"-fields), which might bring up the question what is the original text it is summarizing? The termAdministrativeon the other hand brings in a certain weight. For me personally readingAdministrative summarybrought up the association and the expectation the entered text must be for something more important than a "plain" description for menu. We tried to come up with an alternative trying to convey that a description is only used in the administrative interface and that it's purpose is being a description. But that made the label even longer and more complicated. In the end the consensus was to suggest to stick to the following pattern already familiar to the user:For the field label use:
DescriptionFor the field description use:
Displays on [the place where the description will be shown]*The field description was not directly part of the issue summary but while going through the pages we've noticed inconsistencies there as well because
Add menu,Add vocabulary, andAdd vieware missing a description.Overall going with the term description is the briefest most clear term most users are already familiar with and by providing a consistent field description the user always knows where the description will be displayed. By adding a field description to the
Add menupage as well that would take care of the raised concern in #7. It would be basically be the approach outlined in the proposal section in #1926692: Menu description is misleading to allow for multiline input but the patch changed instead of adding a field description the field label toAdministrative summary.In regards of consistency two more points have to be noted that are probably out of the scope for this issue.
1. on
/admin/structure/views/addaside the fact that the description field doesn't have a field description, that description field is also opt-in. You have to click the description checkbox before you are able to enter an actual description. No matter if a description is entered or not the description column is shown anyway onadmin/structure/views. Instead of hiding the field behind an opt-in checkbox the suggestion is to directly show the description field on/admin/structure/views/add.2. the adding a content block page surfaced a more general issue in particular if you apply the patch for #3325167: Revisit the redirect to 'add block' form in the 'add block content' form alongside.
block/add/basic?destination=/admin/content/blockyou see the required fieldBlock description. Based on the label you could add a verbose description what a block is actually about like for example:save and configurebuttonconfigure blockpage and the machine name gets adjusted accordingly.save=> you will run into an error message "Machine-readable name cannot be longer than 64 characters but is currently 139 characters long."
so it is sort of confusing that you are required to enter a
descriptionfor the content block on the first page which is treated like thetitleon/admin/content/blockwhere you dont have atitlecolumn like on/admin/contentbut ablock descriptioncolumn instead. the expectation on the user end aside the described problem about the field length is the general role. the title is the label for an entity while the role of a description is to actually describe an entity label further in case the sole title isn't clear enough. by reversing the order and first requiring the description and then mirror the entered description to the title field complicates things further.I'll add the need follow up issue tag and remove the needs usability review one.
Comment #32
atul4drupal commentedThanks @rkoller for taking this up in the Usability meeting and sharing the gist's here.
"consistency is a good thing", #24 I expressed my alignment with this (hopefully I am getting good at UX nuances :))
We may make the descriptions and labels consistent as suggested in #31.
Comment #33
rkollerI've just realized another inconsistency and place the term "Administrative" is used. When you create a view the term
descriptionis used on/admin/structure/views/add as described in the issue summary. But if you edit an existing view and you want edit its displays, the button is labeled withEdit view name/description. But within the dialog modal after clicking the button you have the field labelsAdministrative name,Administrative description(with a description for the field missing) andAdministrative tags.