Problem/Motivation

This issue is spun off from #1847596: Remove Taxonomy term reference field in favor of Entity reference.

The bundle selection for an entity reference field is probably the most important piece of configuration for that field. E.g., in the case of a node reference, the user wants to create a reference to their song nodes on their album nodes. In the case of taxonomy, the user wants to add their topic vocabulary to their pages. It's the first thing the user probably wants to choose.

Currently, however the bundle selection for reference fields is buried on the bottom of the third screen of the field creation workflow, under a fieldset ("Reference type") and parent field ("Reference method," "default") that, to the end user, have nothing to do with selecting the bundle they want to use. This makes adding and configuring ER fields confusing.

bundles.png

Proposed resolution

There are a few ways we could go about fixing this, all with pros and cons, not necessarily mutually exclusive.

  • 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?)
  • By default, only enable the default reference method. Make overriding the reference method with a view or such a separate configuration.
  • 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?
  • Improve the label for the "default" reference method.
  • Improve the labeling for the "reference type" and "reference method".
  • Other suggestions?

Remaining tasks

  • Discuss possible approaches.

User interface changes

TBD

API changes

TBD

Members fund testing for the Drupal project. Drupal Association Learn more

Comments

amateescu’s picture

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..

xjm’s picture

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*).

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

IMHO there has to be some way to simplify the 80% (more like 95%) case of selecting a reference for one bundle while sill allowing the underlying flexibility of selecting multiple bundle types, filtering entities with a view, etc. We just haven't found it yet. :)

xjm’s picture

Another crazy thought. What if we added something like an "Add a field to..." option to the dropbutton for referenceable entity bundles (content types, vocabularies, etc.) It would mean introducing an additional possible workflow, and I've no idea how we'd accomplish that in the backend, but it would make it a ton easier to create to just quickly create a term reference or content type reference field. It would also help address one of the ongoing usability problems throughout Drupal: "I made this thing, but now how do I put it somewhere?"

yched’s picture

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.

xjm’s picture

Priority: Normal » Major

Bumping to major since this is one of the few outstanding usability issues following all the work that went in around #1847596: Remove Taxonomy term reference field in favor of Entity reference.

xjm’s picture

Issue summary: View changes
mgifford’s picture

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

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

yched’s picture

@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 ?

mgifford’s picture

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.

damiankloip’s picture

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.

Gábor Hojtsy’s picture

Version: 8.0.x-dev » 8.1.x-dev

Definitely only possible in 8.1 or later now.

Gábor Hojtsy’s picture

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

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

jibran’s picture

Component: entity_reference.module » entity system

Moving to right component

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

xjm’s picture

xjm’s picture

vijaycs85’s picture

Status: Active » Needs review
FileSize
2.62 KB
291.15 KB

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.

Status: Needs review » Needs work

The last submitted patch, 21: 1953568-21.patch, failed testing. View results

marcoscano’s picture

Status: Needs work » Needs review
Issue tags: +Needs usability review
FileSize
35.75 KB
35.76 KB
4.91 KB
3.26 KB

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:

before

After:

after

Opinions?

Berdir’s picture

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?

marcoscano’s picture

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:

reference method in fieldset

fieldset open

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

benjifisher’s picture

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.

Berdir’s picture

> 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.

marcoscano’s picture

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)

marcoscano’s picture

And now without the garbage variable left over..

Berdir’s picture

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.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.