Make the bundle settings for entity reference fields more visible.

Make the bundle selection a field-level setting rather than an instance setting. (What is the usecase for having wholly different referenced data on instances of the same field?)

This is a major limitation in the D7 contrib module, which I worked hard to remove from the D8 code, see #1340098: Move target bundle to the field instance settings. @andypost will hunt you down for even suggesting it, he was pretty vocal about this specific issue in Munich :)

By default, only enable the default reference method. Make overriding the reference method with a view or such a separate configuration.

I guess this could be done, but then the complexity is added in another place. And the ability to provide the entity selection list through a view is also a much requested feature (242 comments!) in contrib: #1253776: Add views support for providing a list of entities or bundles (views filtering, relationships, etc)

Move the bundle selection up above the fold somehow. It doesn't make sense for it to be after the default value list, since it determines what's possible in the default value list. Is the current form ordering the result of Field API limitations?

The bundle selection is provided by that 'default' setting, so I don't see how it could be moved from below it without a very distracting UX (change the value of a select widget and see that some part of the form was changed *above*).

After all that, I see label improvements and probably adding more description text as our only real choice here..

Maybe hide the "Reference method" select by default, only keep the "list of referenceable bundles" checkboxes visible, with an "advanced" link or button that shows the "method" select back ?
When editing an existing field that uses a method other than "default", the form is displayed in "advanced" mode upfront.
I guess accessibility constraints imply doing this through ajax ?

Doesn't preclude the "initiate 'add reference field' action from the admin page of the bundle you want to reference" flow proposed in #3, but seems simpler to implement. I'm not sure how e_r would figure out the locations (which pages / in which dropbuttons) it should add that "add a field referencing that bundle" link.

@yched - trying to understand your point on accessibility " I guess accessibility constraints imply doing this through ajax ?"

I'm just not a JS guy....

@mgifford : that's a long time ago :-), but I think what I meant is that I'm not sure the UI I proposed in #5 can be done purely with one form modified by JS #states, it does more seem like a case for a full-fledged ajaxified form with roundtrips to the server and ajax form rebuilds ?

No problem @yched this happens to everyone from time to time.

It sounds like there's still hope for this in 8.0 and that we shouldn't be bumping it to 8.1 yet.

See https://www.drupal.org/node/1953444#comment-10648838 - you cannot set up a reference field via the UA that references all bundles (unless you select them all manually) as the form element is required, which is pretty terrible.

Definitely only possible in 8.1 or later now.

An additional problem now is the final checkbox for creating new items lines up well with the bundle selection and is confusing:

Moving to right component

If we are trying to fix the UX problem here, is it bad to fix on UI level instead of changing the logic? I tried the above patch and can confirm the basic CRUD works fine.

This is pretty much a WIP / PoC patch, but I wanted to get feedback before proceeding on this direction.

1) Rerolled previous patch
2) Not sure if we want field settings fieldset on the top of the page for all fields, but maybe yes?
Now that I think about it, probably the settings specific for the field are generally more important than the common settings (such as "Help text", required, etc). It may generate some initial surprise to users already used to having them at the bottom, but in the end I think the gain for new users compensates that, and it probably makes more sense in a general perspective.
3) Changed the fieldset label from "Reference type" to "Reference options", which seems to be more accurate.
4) Re-ordered things inside the field settings form to have the bundles checkboxes first.

Before:

After:

Opinions?

I understand that bundle settings are in a way more important than the reference type, at least as long as you do want to use the default. However, they are depending on the type, so with that order, changing the reference type would change the form elements *above* that select, which is pretty uncommon and I think nothing we do anywhere else?

Maybe we can keep the order but find better labels and a description for it or so?

Re #24:
True, it's weird having something change *above* the element you just interacted with... however I still think maybe 90% of users (wild guess) never change the reference method, so the "weirdness" for the 10% users would be compensated by reducing the confusion for the other 90%, who don't even know what this "Reference method" even is?

Another option is just to hide it in a collapsed element maybe?

This is just a mock I created manipulating the HTML in the browser, not sure if it would work:

(Note: I personally still prefer #23, but maybe this can be a good compromise)

We discussed this at the weekly UX meeting today. I think that @yoroy was taking notes, but here are the suggestions that I remember.

Moving these options closer to the top of the page is a good idea. We should normally put required elements first.

Consider removing the fieldset that contains these elements.

Nested, collapsible fieldsets are not really good. If you go with the previous suggestion, then it might be all right to put the "Reference method" in a collapsed fieldset.

I think most of us agreed that the "Reference method" should not be placed below the options that it affects.

> Moving these options closer to the top of the page is a good idea. We should normally put required elements first.

> I think most of us agreed that the "Reference method" should not be placed below the options that it affects.

The problem is that everything inside Reference options below Reference method is depending on that select, so those statements kind of contract each other. The only thing we can do is put the whole fieldset up, but be aware that this will affect all field-type specific settings of all field types. For example that includes settings about link title for link fields, title/alt settings of an image field and so on. And we can't split it up, all of that is inside a container as there is the generic part and then we include the field-type specific stufff.

OK, starting over with a less ambitious approach.

In this patch, I have:

• Replaced the fieldset title Reference type by Reference options, which to me seems a little bit more appropriate
• Moved the checkbox Create referenced entities if they don't already exist to the bottom of the fieldset, once it's not one of the main things in there.
• Bubbled up to the top of the page (only after the field label) the whole settings fieldset. This approach of "moving up" the fieldset will only affect settings of the entity_reference fields. The drawback is that the code looks a little bit more hackish, once we are using a form-alter approach...

Current 8.5.x HEAD:

After the patch applied:

(Note: no interdiff because this is a very different approach)

And now without the garbage variable left over..

For the record, I'm not saying we must only do it for the entity reference field. Just that we need to consider the impact of doing it for all fields. I think it might actually make a lot of sense to do that, but we'll need to go through at least all the core field types with field-level settings. Or we can do it just for entity reference here with a follow-up. No strong opinion, I'm just trying to make sure that we consider all cases.

Below are my notes from yesterday review of this issue during the UX team.

• Field settings are generally more import than the default value. (Entity reference and link fields are good examples)
• Label, help text, and required should always be first since they are applicable to all fields.
• Inline elements should ideally come before details elements
• The simplest approach is to move the Default value as the last element.

Below are before and after screenshots for this approach.

Entity reference before

Entity reference after

Link before

Link after

I have attached a patch that changes the #weight of the default value details widget.

In terms of changing the labeling of "Reference type" to "Reference options". We felt there should be a standard convention for field settings labeling, maybe something like '@field_label option's and this would change the entity reference details widget to be label 'Entity reference options'.

On a personal note, I have struggled with the managing of webform element settings and decided to always group the general and required settings in fieldsets and optional settings in details. I have also applied the naming convention of '@element_type settings' for element related settings.

We discussed this issue again at the Drupal usability meeting yesterday (2019-01-08). Recording here: https://www.youtube.com/watch?v=X2HTetMZwys

I read #27 about five times, and I do not see a conflict between the two quoted suggestions. Maybe @Berdir missed one of my "not"s? Probably it does not matter: see the recommendations below.

Has this behavior changed since Comment #2 was added?

Well, this is already happening with the default values, since changing the allowed bundles changes the possible default values.

In my testing, the only time the defaults change is when I save and reload the configuration form.

Usability review

There are a few problems with the patch proposed in #29:

1. It is confusing to have field elements not wrapped in a fieldset (or details element) after other field elements that are wrapped in such an element.
2. It is inconsistent with other field types, which have the common elements (Label, Help text, Required checkbox) together. As @marcoscano said in #28, the form-alter approach "looks a little bit more hackish".

@jrockowitz's patch in #33 is based on the recommendations we agreed to during the meeting:

1. Do not change any text (such as "Reference type" to "Reference options") as part of this issue. (Narrow the scope.)
2. Move the "Default value" section to the bottom (right above the action links): minimal change to improve this issue.
3. Make this change for all field types. (Expand the scope relative to the patch in #29.)
4. Address other improvements in follow-up issues.

For the record: @jrockowitz is the maintainer of the Webform module for Drupal 8.

I added #3024854: Wrap field-type settings in a fieldset as a follow-up issue.

I reviewed the patch from #33. (That was easy.) I tested with both taxoomy-term and media references. In both cases, I was able to see most of the "Reference type" fieldset without scrolling with my browser window at its normal size.

Every other form element in FieldConfigEditForm::form() is already assigned a weight, and the order of the elements by weight is the same as the order in which they appear in the function. It is a little inconsistent that the first few elements ('label', 'description', 'required') leave room for other weights: they are given weights -20, -10, -5. The remaining elements ('settings', 'third_party_settings', 'default_value') have weights 10, 11, 12 (after the patch in #33).

(Technical point: if the field settings are locked, then none of those elements are added to the form. Instead, there is a single element, 'locked', and it is not given a weight.)

+1 to RTBC

It is a little inconsistent that the first few elements ('label', 'description', 'required') leave room for other weights: they are given weights -20, -10, -5. The remaining elements ('settings', 'third_party_settings', 'default_value') have weights 10, 11, 12 (after the patch in #33).

If we want, we might assign a weight of 20 to the 'default value' fieldset to leave a bit more space, but otherwise I don't think we need to do more than necessary within this issue's scope. There's no right or wrong when it comes to weights, though some room for non-fractional in-between values is nice for contrib needs we can't fully anticipate.

Agree this is RTBC.

Opened another followup to tackle an oddity: #3038199: Reorder reference options in entity reference bundle settings.

Demoted to normal. While the initially planned elephant might have been a major improvement, the mouse that was left in the end, isn't anymore.

But let this be a step-by-step endeavor. It may not be of major priority, but still is a nice little UI improvement.

Wow, many twists and turns here! :)

I think the screenshots in #33 represent a nice iterative improvement. It gets the entity reference required settings at least a little closer to the top. Thanks for all the thought and effort that went into this!

Committed and pushed to 8.8.x. Thanks!