Beta phase evaluation
Issue category | Feature request |
---|---|
Issue priority | Normal |
Prioritized changes | Usability and sites builder experience improvement |
Disruption | None, no BC breaks or migration concerns |
Note: The bug in the original post is no longer an issue so this is technically a feature request. Though the reason the bug was reported is likely because they missed the "Use field label" option, which this issue is now trying to remedy.
Problem/Motivation
When you have a Boolean field within a Content Type, you must define a Field label (e.g., a question to be answered "Yes" or "No"), and a label for each of the two possible answers (On/Off, Yes/No, True/False, etc.). Optionally, you can define some help text.
This is what it would look like to the end user if we had a Field with "Owns a car?" as label, with "Yes" and "No" as On/Off labels.
When the site manager later wants to use add Content of said Content Type, the Boolean field is shown as a checkbox with the "On" value's label, and the help text. However, the Field label and the "Off" value label are not shown. Thus, the site manager doesn't know what question this Boolean field is answering, unless specified on the help text.
This is the field info.
This is what the site manager sees when trying to add content.
Proposed resolution
Edit the Add Content form so that the Field label for Boolean Fields is also shown.
Remaining tasks
User interface changes
Edit the Add Content form so that the Field label for Boolean Fields is also shown.
API changes
Replication Steps
1. Go to Manage -> Structure -> Content types.
2. Manage fields for a content type.
3. Add a Field of type Boolean.
4. Label it with a Yes/No question (Does this person smoke?).
5. Set the "On" and "Off" labels to any value.
6. Go to Content.
7. Add Content of the type we just added a Boolean Field to.
You will see the checkbox with the "On" label, but not the question (the Field label), so you don't know what the field is answering (unless specified in the help text).
Original report by @R. Volk
// I didn't found an similar issue, so i created this one. Please close if duplicated or already fixed in newer versions.
Boolean fields has no labels in the node edit form.
1. edit a content type
2. create a boolean field "Bug"
3. use "Yes" and "No" as labels
4. open the node edit page, you will finde a single checkbox with "Yes" besides, but you don't know what yes means
[x] Yes
instead of:
Bug:
[x] Yes
Comment | File | Size | Author |
---|---|---|---|
#30 | 2361469-30-boolean-field-settings.patch | 3.05 KB | mikeker |
#25 | 2361469-25_boolean-field-settings.patch | 3.05 KB | mikeker |
#20 | 2361469-20_boolean-field-settings.patch | 3.02 KB | mikeker |
#16 | 2361469-d.jpg | 106.58 KB | Andres Mejia |
#16 | 2361469-c.jpg | 97.22 KB | Andres Mejia |
Comments
Comment #1
dawehner... please always report and test against 8.0.x-dev Thank you!
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedI could reproduce the issue, and made a test that demontrates the lack of the label. However, I'm not sure what the correct behaviour should be (not showing a label is default for checkboxes).
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedComment #5
geffio CreditAttribution: geffio commentedComment #6
Shreya Shetty CreditAttribution: Shreya Shetty commentedComment #7
Shreya Shetty CreditAttribution: Shreya Shetty commentedComment #8
Anonymous (not verified) CreditAttribution: Anonymous commented@Geffio: There is a difference when editing a form (your screenshot 1) or looking at a node (your schreenshot 2). If you look at the promotion options in the edit form, you'll see they also don't have a label. That's what makes me hesitate what the intended behaviour on a form is.
Comment #9
Shreya Shetty CreditAttribution: Shreya Shetty commentedHi R. Volk ,
I have made changes as guided by you.Please review and tell if further improvements have to be made.
Comment #10
Shreya Shetty CreditAttribution: Shreya Shetty commentedComment #11
swentel CreditAttribution: swentel commentedIIRC, you should be able to set the label on the manage form display. I think we should probably make that as the default.
As far as I can see the patch is make exceptions in the base field edit form, we should look at the widget for booleans instead.
That's in BooleanCheckboxWidget and maybe we should set 'display_label' to TRUE by default.
Comment #12
Andres Mejia CreditAttribution: Andres Mejia commentedI am taking some screenshots to illustrate the complete procedure using Boolean fields.
Comment #13
Anonymous (not verified) CreditAttribution: Anonymous commentedComment #14
Andres Mejia CreditAttribution: Andres Mejia commentedI managed to compose 2 mockups for better analysis.
Comment #15
Andres Mejia CreditAttribution: Andres Mejia commentedComment #16
Andres Mejia CreditAttribution: Andres Mejia commentedThis is my proposal on how the functionality should work, since it provides a more usable.
Comment #17
ariadni-sofia CreditAttribution: ariadni-sofia commentedYou could use the radio button option instead of checkbox. In this way you will have 2 boxes with yes/no, on/off option
i hope to help you
Comment #18
ariadni-sofia CreditAttribution: ariadni-sofia commentedComment #19
mikeker CreditAttribution: mikeker commentedI agree with @swentel in #11 -- the default for the single on/off widget should be to use the field label instead of the "On label." That will reduce confusion when adding new Boolean fields as that's how most existing Boolean fields are configured (eg: Promoted to front page).
However I don't agree with the proposal in #16. I don't see why the field label should be repeated as in the second screenshot.
Comment #20
mikeker CreditAttribution: mikeker commentedDifferent approach to that taken with earlier patch so no interdiff. This changes the default value of the Use field label instead of the "On label" as label option from FALSE to TRUE and adjust the tests accordingly.
On a sidenote, I think "Use field label instead of the "On label" as label" is in the running for most confusing sentence in Drupal... :)
Comment #21
mikeker CreditAttribution: mikeker commentedAdded beta eval and note just above issue summary.
Comment #22
mikeker CreditAttribution: mikeker commentedBetter describes what is happening.
Comment #23
mikeker CreditAttribution: mikeker as a volunteer commentedPatch still applies cleanly.
Comment #25
mikeker CreditAttribution: mikeker as a volunteer commentedRerolled.
Comment #27
jhedstromThe patch in #25 still applies (with fuzz). I manually tested and it works as expected, and much improves the default behavior for adding a single checkbox. The approach taken is that suggested in #11. Tagging for UX review.
Comment #28
yoroy CreditAttribution: yoroy at Roy Scholten commentedEnough fuzz in the patch for simplytest to reject it, so couldn't test manually. From reading the issue and looking at the screenshots this makes a lot of sense: it removes confusion by providing a better default. Win!
Not rtbc'ing because I don't know if we should present core committers fuzzy patches :)
Comment #29
jhedstromCould somebody reroll so we don't present the committers with fuzz? :)
Comment #30
mikeker CreditAttribution: mikeker as a volunteer commentedDefuzzed.
Comment #31
jhedstromI think this is now safe to RTBC.
Comment #33
mikeker CreditAttribution: mikeker as a volunteer commentedI think the failure is unrelated.... Retesting.
Comment #34
yoroy CreditAttribution: yoroy at Roy Scholten commentedComment #35
xjmI tested this both with and without the patch, and I definitely agree that the default being added by the patch makes the most sense. What's more, all the default config that ships with core already uses this setting, which also points to it being a more useful default. The updates to the test coverage also look good, and we have signoffs from both usability and field maintainers.
I also tested and confirmed that when one switches the widget to radio buttons, that still uses the yes/no labels as expected, and that switching back to a single checkbox afterward also goes back to the new default.
One concern I did have is that with this default we would have the reverse problem. When the site builder sets up the field and enters "On" and "Off" labels without changing the form display, the first time they create the content, it seems like the "On" and "Off" labels don't do anything. But then they will still see them by default as soon as they save the content, so that is fine.
I checked to confirm that we did not need to update any default config for this setting, and there is no change to the schema because it is a default value. So there is no need for an update path. (Obviously, we can't change fields on sites that are already installed because site owners will have configured that on purpose as well. The same is true for migrations, and I confirmed that this setting does have a migration already; see #2260239: D6->D8 Profile field (checkbox)).
Committed a1529fe and pushed to 8.2.x. Thanks!