Problem/Motivation
There's several boxes on the fields page ... the two I have issue with are the "Type of data to store." box and "Form element to edit the data." box.
They both start with a default "-Select a field type-" and "-Select a widget type-" options, which is great.
But, once you select a field type, the widget box loses its default option, which is really, REALLY confusing when the first option is "Select list" and you are selecting a list type and can't find the dropdown box option.
Clarification about the issue : http://drupal.org/node/1001728#comment-4985424
Proposed resolution
Could you please put the "-Select a widget type-" back on the widget dropdown as the default option once it has some data loaded in it, so it isn't so confusing and inconsistent?
Remaining tasks
To see if this is an issue.
User interface changes
To be determined.
API changes
To be determined.
Original report by giraffian
There's several boxes on the fields page ... the two I have issue with are the "Type of data to store." box and "Form element to edit the data." box.
They both start with a default "-Select a field type-" and "-Select a widget type-" options, which is great.
But, once you select a field type, the widget box loses its default option, which is really, REALLY confusing when the first option is "Select list" and you are selecting a list type and can't find the dropdown box option.
Could you please put the "-Select a widget type-" back on the widget dropdown as the default option once it has some data loaded in it, so it isn't so confusing and inconsistent?
Comment | File | Size | Author |
---|---|---|---|
#9 | drupal8.field-ui-add-field-option.9.patch | 1.74 KB | sun |
#4 | select-list.png | 31.86 KB | yoroy |
Comments
Comment #1
yched CreditAttribution: yched commentedrecategorizing
Comment #2
sunI'm not sure I fully understand the summary - could use some clarification or "steps to reproduce" or something (in the summary).
Comment #3
RumpledElf CreditAttribution: RumpledElf commentedGo to admin/structure/content types/ [content type] / manage fields
Add a new field - the two rightmost boxes are "- Select a field type -" and "- Select a widget - "
Choose any of the "List" field types or a term reference field type.
The widget box immediately changes to "Select list" as the default selection.
Which is misleading, as you have chosen a "list" type, and it is asking you to select what kind of list you want, but the first option is "Select list".
So you are, effectively, selecting a select list from the select list of list selections.
In #drupal and #drupal-support I've bumped into quite a few people (new users) who can't work out how to get a select list widget, as when they go pick a list type they say there is only one choice (or two for the term field type)- the "Check boxes/radio buttons" option. So you have to tell them that the first option of "Select list" doesn't actually mean select a list type, it means the select list type of list.
I know its a bit of a terminology problem with the actual html element being called a select list, but still ... it's no wonder why people get confused!
Even renaming "Select list" to "Dropdown list" would eliminate this one.
Comment #4
yoroy CreditAttribution: yoroy commentedThe confusion is around terminology indeed, but a select list is called a select list, so it will be hard to change that. The one time where an alphabetical sorting of options would help avoid confusion, the options are not sorted alphabetically :)
If the first option would be 'checkboxes/radio buttons' the potential confusion would be taken away I think.
Comment #5
sunThanks @yoroy, that clarifies a lot :) Hopefully, better issue title.
Sorting alphabetically wouldn't hurt anyway. Though I'm not sure whether it's the ultimate answer -- since translations for other languages may be ordered wonkily again. ;)
Comment #6
yched CreditAttribution: yched commentedBesides, I think that when adding new field, we pre-select the widget that is marked as being the 'default widget' for the field type (not 100% sure, cannot dig in the code right now, but even if we don't currently, we probably should).
For List fields, the default widget is the 'Select list'. So you'd always see 'Select list' as the preselected widget when picking a List field, regardless of the sorting of the options in the dropdown.
Comment #7
RumpledElf CreditAttribution: RumpledElf commentedIts still confusing for noobs. They come into irc and ask how you do a dropdown box because there's no option for it in the UI. Then you tell them its 'select list' and they go 'oh, I didn't know that was something you could choose'.
All this would take to fix is add -select- to that box at the top.
Comment #8
yoroy CreditAttribution: yoroy commentedCorrect, thats the right way to fix it. Anybody up for a patch?
Comment #9
sunThat would have to be a very custom "- Select -" option, because the built-in of Form API is automatically removed as soon as the select list has a default value already. That is, this happens for #required select lists only. However, this select list here is required, since every field needs to have a widget configured.
That said, as @yched already mentioned, we seem to pre-select the default widget. Obviously, we could just remove that pre-selection and Form API would expose the #empty_option "- Select -".
However, there might also be a usability point in pre-selecting the default widget, in the sense of "simplify the 80% use-case"... ;)
And lastly, all of this still doesn't apply to the case when editing an existing field. But then again, the screenshot here only shows the "Add field" form, so there might not be an issue with the field edit form...?
Anyway, attached patch retains the default select option.
Comment #11
yched CreditAttribution: yched commented- I'm puzzled by the test fails. It seems that setting the 'widget type' selects to '#required' prevents the submission of the 'add new field' row.
$edit = array(The code is the following :
'fields[_add_new_field][label]'=> 'Some label',
'fields[_add_new_field][field_name]' => 'field_foo,
'fields[_add_new_field][type]' => 'number_integer',
'fields[_add_new_field][widget_type]' => 'number',
);
$this->drupalPost('admin/structure/types/manage/article/fields', $edit, t('Save'));
?>
Beats me for now.
- I was on crack, we currently don't actually pre-select the 'default' widget for the field type. Info about "default widgets" are not part of the data we pass in drupal.settings for the JS side.
- Consequently, when reacting to "the value of 'field type' selector of the 'add new field' row has changed", our helper jQuery.fn.fieldUIPopulateOptions() function gets called with no 'selected' param (that's intended), and no option gets marked as 'selected'.
With the current patch, this means that the 1st option (the "- Select a widget -" option that gets re-added) appears selected, instead of an actual, valid widget, which is a UX loss.
Comment #12
xjmSee also #1317884: Remove all instances of <none>, <Hidden> and <br/> from translatable strings because they lead to import errors; the issue of punctuation to denote "pseudo-options" has come up there as well.
Comment #13
Bojhan CreditAttribution: Bojhan commentedI am not really convinced of this problem, nor that we are really making it better with the approach.
Yes it can be confusing, but the trade off is quite big and I am not sure that it is worth it.
Comment #14
ksenzeeI wonder if simply renaming it from "Select list" to "Select list/dropdown" or something like that would solve the problem?
Comment #15
joekrukoskyI agree this is not an issue. When the field type is selected the widget field darkens and the dashes disappear. Reasonably, this should indicate that a default choice was made.
Comment #16
latulipeblanche CreditAttribution: latulipeblanche commentedEdit the issue summery so that it has the standardized form. (http://drupal.org/node/1427826)
Comment #17
swentel CreditAttribution: swentel commentedThe widget is not selected anymore on the manage fields page, but on 'Manage form display' in D8.
Comment #17.0
swentel CreditAttribution: swentel commentedUpdated the issue summary.