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.
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
Related Issues
Comment | File | Size | Author |
---|---|---|---|
#33 | drupal-1953568-33.patch | 610 bytes | jrockowitz |
#33 | webform-example.png | 131.94 KB | jrockowitz |
#33 | entity-reference-after.png | 121.28 KB | jrockowitz |
#33 | entity-reference-before.png | 121.25 KB | jrockowitz |
#33 | link-after.png | 124.4 KB | jrockowitz |
Comments
Comment #1
amateescu CreditAttribution: amateescu commentedThis 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 :)
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)
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..
Comment #2
xjmWell, 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. :)
Comment #3
xjmAnother 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?"
Comment #5
yched CreditAttribution: yched commentedMaybe 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.
Comment #6
xjmBumping 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.
Comment #7
xjmComment #8
mgifford@yched - trying to understand your point on accessibility " I guess accessibility constraints imply doing this through ajax ?"
I'm just not a JS guy....
Comment #9
yched CreditAttribution: yched commented@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 ?
Comment #10
mgiffordNo 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.
Comment #11
damiankloip CreditAttribution: damiankloip commentedSee 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.
Comment #12
Gábor HojtsyDefinitely only possible in 8.1 or later now.
Comment #13
Gábor HojtsyAn additional problem now is the final checkbox for creating new items lines up well with the bundle selection and is confusing:
Comment #16
jibranMoving to right component
Comment #19
xjmThis usability issue has come up again in the media initiative; usability reviewers brought it up on #2831943: Use "rendered media" (not links) as default media field formatter; add modal to configure the used media view mode. We've been discussing parts of it on #2895001: Use the bundle label (e.g. "Media type") instead of "Bundles" in the Entity Reference field configuration as well.
Comment #20
xjmProposals from #2895001: Use the bundle label (e.g. "Media type") instead of "Bundles" in the Entity Reference field configuration which I've rescoped to not overlap with this issue:
Comment #21
vijaycs85If 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.
Comment #23
marcoscanoThis 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?
Comment #24
BerdirI 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?
Comment #25
marcoscanoRe #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)
Comment #26
benjifisherWe 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.
Comment #27
Berdir> 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.
Comment #28
marcoscanoOK, starting over with a less ambitious approach.
In this patch, I have:
Reference type
byReference options
, which to me seems a little bit more appropriateCreate 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.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)
Comment #29
marcoscanoAnd now without the garbage variable left over..
Comment #30
BerdirFor 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.
Comment #33
jrockowitz CreditAttribution: jrockowitz as a volunteer and at The Big Blue House commentedBelow are my notes from yesterday review of this issue during the UX team.
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.
Comment #34
benjifisherWe 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?
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:
@jrockowitz's patch in #33 is based on the recommendations we agreed to during the meeting:
For the record: @jrockowitz is the maintainer of the Webform module for Drupal 8.
Comment #35
benjifisherComment #36
benjifisherI added #3024854: Wrap field-type settings in a fieldset as a follow-up issue.
Comment #37
benjifisherI 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.)
Comment #38
knyshuk.vova CreditAttribution: knyshuk.vova at Internetdevels, Drupal Ukraine Community commented+1 to RTBC
Comment #39
PanchoIf 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.
Comment #40
PanchoDemoted 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.
Comment #42
webchickWow, 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!