In #1801304: Add Entity reference field there was a discussion concerning UX, about how when to present the user the entity-type for reference. Should it be done on the field type - multiple field types called Node reference; Comment reference; Or a single field type called Entity reference, and in the field settings allow user to select the entity type.
See yched's comment and amateescu's answer

CommentFileSizeAuthor
#28 reference-fields-ux-001.png100.2 KByoroy
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

amateescu’s picture

Title: Meta: Discuss the concept of sub-widgets to allow better UX for Entity-reference » Discuss the concept of sub-fields to allow better UX for Entity reference

Reworded the title a bit.

xjm’s picture

This could use a more detailed summary. :)

effulgentsia’s picture

Title: Discuss the concept of sub-fields to allow better UX for Entity reference » Discuss the concept of sub-field-types to allow better UX for Entity reference

Reading #1801304-102: Add Entity reference field, #1801304-107: Add Entity reference field, #1847596-119: Remove Taxonomy term reference field in favor of Entity reference (and some of the replies to it), I get the sense that people more or less agree that changing the UI so that administrators are not exposed to a generic "Reference" or "Entity Reference" field type, but instead are exposed to "Content Reference", "User Reference", "Term Reference", etc., would be desirable.

I think some people even consider it not only desirable, but possibly even a major or critical requirement, especially once #1847596: Remove Taxonomy term reference field in favor of Entity reference lands.

The only concern I found while quickly skimming the discussion is on #1801304-107: Add Entity reference field:

Damien is really against chaging the current approach without having a sub-field-type concept in field api.

So, perhaps the question here is: what is missing from Field API to support this? Is it just a matter of converting field types to plugins (which we need to do anyway, needs a specific issue, #1949932: [META] Unify entity fields and field API is the closest meta issue related to that), at which time, we just implement sub-field-types as derivative plugins, and that's it? Or is there something else about Field API that's in the way and needs fixing?

yched’s picture

"derivative" field types when field types are plugins will still be seen, from the outside, as separate field types, just supported by the same single class - and I'm all in favor of that.

I have no clue what a "sub-field-type" would be, or what meaning people have been putting on this, but this very much sounds like a blurry concept that I have no real desire to explore this late in the cycle :-/.

xjm’s picture

Issue tags: +Usability

All I think we really need is to expose the "Reference" field type multiple times in the field type select on the manage fields page as "Taxonomy term reference," "User reference," "File reference," "My foo-entity reference," etc. I personally don't care if there's a pretty API for it or not. Even altering it on would be much better than the current behavior; we can always refactor it to be cleaner later.

Berdir’s picture

Not sure if altering it in would really work, that sounds ugly.

Wondering if we want to give entity types a way to control this or enable it only for some of them. There are already a ton of entity types on big 7.x sites and 8.x will probably have even more although a lot will be config entities. But we might end up supporting them too.

amateescu’s picture

Re #3:

So, perhaps the question here is: what is missing from Field API to support this? Is it just a matter of converting field types to plugins ..., at which time, we just implement sub-field-types as derivative plugins, and that's it?

IMO yes, but I can't speak for Damien.

Re #5:

.. we can always refactor it to be cleaner later.

I think we're pretty much in the 'later' phase of the cycle, so *now* would be the time to do it :P

Re #6:

Wondering if we want to give entity types a way to control this or enable it only for some of them. There are already a ton of entity types on big 7.x sites and 8.x will probably have even more although a lot will be config entities. But we might end up supporting them too.

This is the actual problem here! Yes, we very much want/need to enable support for config entity types. Then, a couple of other question rise:

Do we want to expose multiple ' Reference' only for content entities? If so, why only for them, if the field supports both?

There are currently 23 entity types in HEAD (with at least 3 more coming), imagine how the field type select widget will look with 26 more options to choose from.. I wouldn't call that a usability improvement.

Couldn't we just adress this issue in documentation? Moving from the D6 style of using taxonomies to the field type approach D7 was hard enough for users, I think that moving to a shorter "Reference" is nothing compared to that.

I also see another option for the UI: have a single "Reference" entry in the main select widget which exposes a secondary list of all possible entity types, and group them using two option groups for 'Content' and 'Config'.

klonos’s picture

There are currently 23 entity types in HEAD (with at least 3 more coming), ...

Yeah, but we'd only need to provide options in the drop-down for only those that were "regressed" from D7 - not for ALL of them. Plus I'm sure that most of these can be logically grouped together.

I realize that those of us suggesting that we add "Taxonomy term reference"/"User reference"/"File reference"/"Content reference" options might be actually special-casing these, but that's not an issue if the end goal is to improve UX (or at least keep it from being degraded).

amateescu’s picture

Title: Discuss the concept of sub-field-types to allow better UX for Entity reference » Discuss the concept of field subtypes to allow better UX for Entity reference

Re #8:

I realize that those of us suggesting that we add "Taxonomy term reference"/"User reference"/"File reference"/"Content reference" options might be actually special-casing these, but that's not an issue if the end goal is to improve UX (or at least keep it from being degraded).

The UX will be degraded nevertheless if we choose to arbitrarily special-case some core entity types. Also, let's not forget that D7 core had only "Term reference", "File" and "Image"!

How about considering to add contrib into the mix (quite possible, right? :)). Let's say that you install Drupal Commerce. In D7, you would have three reference fields added to that list: Customer profile reference, Line item reference and Product reference. What would a user say when he doesn't see these as an option anymore? "Ugh.. Commerce in D8 looks broken, let's try something else" :P

Or let's say we special case those too. And a dozen of other entity-providing contrib will do that as well, why not? We could easily get to those 26 "* reference" options with content entity types alone.

What I want to stress out here is that we're not in code freeze yet, so we still have the option to change Field UI to better suit this.. "problem".

Dave Reid’s picture

What is better? 26 different but discrete reference options in an improved field UI selection, or site builders that have to learn the new concepts and terminologies? Sure, as developers entity reference as one field makes sense to us. But if we actually go out and did usability testing on real site builders would we find the same result?

xjm’s picture

The point about the number of sheer number of entity types is a good one and is something we also discussed when reviewing the taxonomy patch and debating what to do about the discoverability problem. Maybe we can let some content entities (like file, user, content, taxonomy) implement a hook to expose their references "first class" references? When the user selects one of these, they get an ER field with the entity type already set.

amateescu’s picture

Re #10:

26 different but discrete reference options in an improved field UI selection

(emphasis mine) .. that's all I ask.

Re #11:
Please see my second to last paragraph in #9..

yoroy’s picture

A couple of scenarios or user stories would help me understand the discussion from a UX point of view.

*edit*: I ask because I'm not sure what the entity reference status is in core right now. I only see a term reference field in Field UI, not sure where to look for the others being discussed.

Berdir’s picture

> references "first class" references?

I think the problem with terms, files and images is actually that it's *not* perceived as a reference.

For actual references (e.g. i have a project node type that has *references* to users that work on it, or articles that talk about it) I can't imagine that site builders have a problem to use a "Reference" field type (as long as we make the follow-up configuration screen usable and the target type more visible) once they understood the concept and I think that's better than having 5 or 10 different field types that you need to search in a long list of types.

I think the problem with those is that users don't see the examples from above as a reference (why would you look for "Reference" when you want to add an autocomplete tags field) so maybe we should find an easy way to special case those (in a way that allows to add contrib modules more special cases)

xjm’s picture

I think the problem with terms, files and images is actually that it's *not* perceived as a reference.

Yeah, that's the problem exactly, I think.

Related (for taxonomy):
#394482: Users should be able to enable a vocabularly from the content type configuration page
#889378: Create taxonomy fields from the taxonomy administration page

xjm’s picture

@yoroy, see the screenshots in: http://drupal.org/node/1847596#comment-7211430

The first one is the step we're discussing here.

xjm’s picture

Title: Discuss the concept of field subtypes to allow better UX for Entity reference » Discuss how to fix UX of entity reference field type selection

@yched in #1847596-132: Remove Taxonomy term reference field in favor of Entity reference:

One possible track for breaking out of the constraints of the current shape of the "select field type" dropdown in Field UI's "add new field" UI could be to remove those "add new field" / "add existing field" as rows in the "Manage Fields" table, and move them to action buttons at the top of the page
Those would lead to separate form steps where the selection of the field type would have more screen real estate available to explore more suitable UX formulations.

This, I think, might be a more promising direction in the long run. I was just thinking about how most field types are actually very simple compared to the reference field. It's almost a meta field type.

xjm’s picture

Title: Discuss how to fix UX of entity reference field type selection » Fx UX of entity reference field type selection
Priority: Normal » Major

Actually, let's be a little more bold here. If we want to convert taxonomy and file references to this in core, this is at least major, and possibly critical (as a UX regression and release blocker).

xjm’s picture

Title: Fx UX of entity reference field type selection » Fix UX of entity reference field type selection

Now with spelling!

yched’s picture

Thinking out loud, chewing on the recent comments about "some entity types would make sense as standalone "reference this entity type" field types in the UI".

When field types are plugins, there might be some way to special-case TermReferenceFieldType as extending EntityReferenceFieldType, just forcing different values for some settings ('target_entity_type' forced to 'taxonomy_term'), and providing no UI to change them.

Drawbacks :
- you can still programmatically define a term_reference field with a setting of 'target_field_type' = 'node', but this just won't stick (or more likely will get written to config as 'taxonomy_term' anyway)
- you can still define a plain entity_reference field having 'target_field_type' = 'taxonomy_term'. It won't be strictly equivalent to a taxonomy_reference field, though - different field types...

tstoeckler’s picture

I think in that case it would be cleaner, although more code, to simply make the EntityReference field an abstract class with an unimplemented targetEntityType() method (and strip out the entity type selection form).

Then each entity that wants to provide a reference field would have to manually subclass that (which would obviously be a drawback) but it would be as easy as.

class TaxonomyTermReference extends EntityReference {
  public function targetEntityType() {
    return 'taxonomy_term';
  }
}

and in contrib one could still add a true configurable entity reference field.

amateescu’s picture

Maybe it's just me, but #20 and #21 are going in a direction that seem to imply that we don't really want a truly generic entity reference field in core? rm -rf core/modules/entity_reference is also an option for that.

xjm’s picture

No one is saying remove the generic reference field functionality. We just want to more easily package the really common usecases. Users in usability tests already struggle with taxonomy as a field in D7, so we need to mitigate the added difficulty of extra abstraction.

Following up for @yoroy, here's the entity reference conversion of term reference fields applied to a simplytest.me sandbox to click through and test it. From #1847596: Remove Taxonomy term reference field in favor of Entity reference. (The latest version of dreditor provides a simplytest.me button on every patch--totally awesome.)

effulgentsia’s picture

Priority: Major » Normal
effulgentsia’s picture

Priority: Normal » Major
tstoeckler’s picture

Re #22: I really didn't want to advocate #21, I was just trying to think of a way to make both camps happy without introducing a huge amount of hacks (although, obviously #21 could certainly be considered un-clean).

The natural and cleanest way to solve this would be plugin derivatives. With that we could expose an entity reference field for every (content) entity in a very natural way. We wouldn't have an actual abstract entity reference field to select in the UI (which seems to be what we want), but actual content entities wouldn't have to do any plumbing themselves, everything would be handled by entity_reference automatically (which is also what we want). So can we just get field types as plugins done, which we want to do anyway, and postpone this issue on that?

David_Rothstein’s picture

I realize that those of us suggesting that we add "Taxonomy term reference"/"User reference"/"File reference"/"Content reference" options might be actually special-casing these, but that's not an issue if the end goal is to improve UX (or at least keep it from being degraded).

The UX will be degraded nevertheless if we choose to arbitrarily special-case some core entity types.... Let's say that you install Drupal Commerce. In D7, you would have three reference fields added to that list: Customer profile reference, Line item reference and Product reference. What would a user say when he doesn't see these as an option anymore? "Ugh.. Commerce in D8 looks broken, let's try something else" :P

I don't think that would necessarily be the case. The way I'd picture the options is something like this:

  • Reference (content)
  • Reference (taxonomy term)
  • Reference (user)
  • .... [any other "special" ones] ...
  • Reference (other)

Hopefully people could figure out to look for other things under "other" :)

yoroy’s picture

FileSize
100.2 KB

So what about first making the basic distinction between a) creating fields for this specific content type and b) adding existing ones from elsewhere.

So when adding a field, have a seperate section at the bottom of the 'select a field type' select list that has a generic worded option to 'Add fields from other items' (or 'Display fields from other items' or similar). That might help establish the general concept of references.

Then when you've chosen that, the immediate next step would be to indicate which kind of fields you want to show. At that stage, we still might want to try and offer some likely candidated immediately, but at this stage that might not provide that much more value.

This is an incomplete thought of course, but I want to try and establish the references concept in laymans terms first, because as berdir and xjm already pointed out, most of the use cases are not necessarily percieved as references. My guess would be that people think of this as linking to, re-using or importing stuff from elsewhere.

effulgentsia’s picture

most of the use cases are not necessarily percieved as references

My read of #14 is that most entity type references *are* perceived as references, in the sense of linking/reusing something from elsewhere, and there's just a small number of entity types where that's not the case and we need to consider as "special". Maybe I'm wrong, but I don't think "add from other item" provides more clarity than "reference".

So what about first making the basic distinction between a) creating fields for this specific content type and b) adding existing ones from elsewhere.

I think the word existing here is a little incorrect, in that even for things like node references, you sometimes want to allow creation of the referenced node if it doesn't already exist. So the general concept of a reference is that you're linking to something that once it exists, will have an independent identity and be linkable from multiple places, but it doesn't necessarily exist before the first place that needs it creates it.

However, the problem is that even for entity types where the "referenceable from multiple places" is true, users don't always think of it that way. For example, core's current file and image fields don't provide a way to reuse the same files and images in multiple places. But Filefield Sources and Media do. And in the case of Media, I've seen many site owners struggle with the concept. So while under the hood, it can all be file references, whether the user thinks of it as a reference or not is use-case and widget specific.

Also, taxonomy terms are interesting, because it *should* be quite clear that it's a reference. Most people understand that if you add a tag to one node, and the same tag to another node, that both nodes are pointing to the same tag. And that you can click the corresponding link and be taken to a page that shows you all nodes with that tag. So I'm very curious as to why users don't think of it as a reference, and whether it's a unique quirk of taxonomy terms, or something that would happen with other entity types too.

yoroy’s picture

Thanks for the details. I think the general term and concept, however 'correct', 'reference' as a word is as abstract (meaningless) as node, entity and the like . which means it doesn't carry enough meaning to be useful, actionable.

Wether or not it *should* be clear is not the point I think. It doesn't to the non-tecnical builder. I know I was absolutely at a loss trying to add a tags field to a node in d7 the first time, and I helped design the damn thing! :-)

Ideally the references concept would dawn on you after succesfully applying it a couple of times, instead of headdesking your way to understanding through google searches or brute forcing through all available options and see what sticks.

Any other suggestions? We need more ideas

effulgentsia’s picture

'reference' as a word is as abstract (meaningless) as node

You likely have more data backing that up than I do, but back when I worked as a freelancer, I never had a client not know what a reference is. I think the web has made people very familiar with what a link is, and a reference is just a link to something within your own site. Though I suppose in some industries (academia, law), people might think it means something else (e.g., a bibliographic citation).

One idea (maybe a bad one) on how to remove this word is if we support field type grouping per #1953836: Replace "Select a field type" with a hierarchical select, then we can have:
- A "Link" group.
- Within that, rename the Link field type to something like "URL" or "External resource".
- Have a field type for each entity type ("Content", "User", ...).
In other words, you first decide you want to link to something, and then your choices are "Content", "User", ..., "External Resource".

I was absolutely at a loss trying to add a tags field to a node in d7 the first time

Maybe one reason taxonomy terms are the problem child here is that for many websites, people don't think of them as independent things, but rather as just words. For example, you could implement tagging functionality with just a text field, a View that showed you all entities containing a certain piece of text in that field, a formatter that rendered the text field as a link to that view, and a autocomplete widget that queried all words already entered for that field in other entities. In fact, Views itself allows you to "tag" a view, and all that really is is a text value, not a term reference. If this is where the cognitive dissonance is happening, then I agree with us needing to address taxonomy terms in some special way, but I don't think we should take that to mean that references are poorly understood in general.

yched’s picture

I'm not sure that switching the meaning of "Link" in a web platform to mean something else than "a hyperlink" is a good idea :-).

Other than that, agreed with #31:
I'm not convinced the word "reference" itself is a problem, when the referenced "thing" is clearly "something that lives outside of the entity I'm adding the field on" in the immediate cognitive model.
So that works for "a user", "a comment", "a product", mostly because those entities have their own separate visual existence on the site. Users and products have their own pages, comments are displayed next to but outside of a node...
Less true for taxonomy terms and files / images, because although technically they are standalone entities just the same and can be reused across multiple entities, they are perceived as being *part of* the node they're attached to : a taxonomy term is seldom "seen" in itself outside the entities it tags, and the core UI for files & images does not actually let you reuse them.

yoroy’s picture

So, what is the suggested approach? I agree the word reference doesnt have to be the problem. What about the idea of putting references at the bottom of the select list?

bojanz’s picture

I don't think there's any problem with the word "reference". Link is certainly worse.

xjm’s picture

For what it's worth, the kind of pattern in #28 is one of the things that was rattling around in my head. Entity reference fields are much more multidimensional than any other field type.

xjm’s picture

xjm’s picture

Pancho’s picture

Trying to put together what we mostly seem to agree on:

  • The current workflow is unacceptable as a major UX regression for the most basic reference types
  • The concept of "Entity reference" must not be exposed to users at all.
  • The word "Reference" is okay. People understand what it is.
  • Taxonomy terms are special, because they are perceived as meta data rather than a "separate thing" (first-class entity) living outside the node (= 80% use case of a fielded entity).
  • Files and images need special treatment, too.
    In line with what @effulgentia said in #29: even though they are seen as objects, and even though they can be leveraged as reusable entities, they are still mostly perceived to live within the node, which was true before D7, which still seems to be true from core UI, and which is still true for most other CMS/Forums/Wikis etc.

Also:

  • Nodes are special in a completely different way.
    Even though they are totally perceived as separate things and it is totally accepted they can be "referenced", this might simply be because they are another 80% use case. Also, this might be because in the 80% use case they are the only entity type with multiple, possibly very different bundles, so we might want to avoid burying these too deep.
  • Comments need no special treatment, even though they are perceived to live within the node they were added to. It is perceived they are referenced as a special section on the node page, a concept users are familiar with from linking to page fragments in HTML or Wikipedia.
  • Users need no special treatment, even though many people won't know what they actually are in D8. They're perceived as something that certainly doesn't live within nodes, so might be referenced. This holds even though there was something like "User references" in D7 contrib.

Now putting all of this into a larger context, I understand that there is quite some resistance to special-case taxonomy terms, files and images, and possibly nodes.
There are pros and cons and there are different ways to achieve this. But in any case I would reinforce the fact that we can't revolutionize the UI just because it code-wise makes sense or because it makes for maximum consistency between entity types, a concept that is absolutely irrelevant and mostly obscure to most admins. As long as we don't educate people that nodes, users, files and terms are something very similar, their intuition doesn't follow a concept of entity types, but of nodes, users, files and terms, as they used to be implemented in most pieces of software.

So yes, while we want to avoid WTFs, we also want to teach Drupal admins that terms, files and images are indeed first level entities. Only if they come to understand that, they can leverage the power and flexibility of this concept.
However, if we want to teach, we need illustrative material and can't just prerequire knowledge. So if from the very first time people are trying out D8 we manage to make it clear that terms, files and images are indeed full entities, if our UI obviously treats them like full entities, then we can safely assume people understand that these can be referenced just the way nodes can be.

For images and files this would mean that we needed a UI such as Media that really lists images and files and exposes galleries. Files and images needed to be rightaway fieldable from the UI. But it's also tiny little hints that add up to the wrong assumption that files and images are no self-contained entities: For example, the description of File module ("Defines a file field type.") suggests that files live in fields. And the description of Image module ("Provides image manipulation tools.") reaffirms that even more that they are just something special. While these descriptions may be correct for what the modules do, they aren't complete in terms of what the modules expose to the users, which is even less than what really happens in the background.

For terms this would mean terms must look and feel more like nodes (as the most well-established entities), vocabularies must look and feel more like node types. For example, Description could become Body, and the listing could become some kind of field (Is it already? Then it needs to be obvious.). And if created on-the-fly, there should be a status message linking to the new terms/tags. And their listings shouldn't be buried so deep in the admin menu. But, as always, we'd need to weigh consistency with a concept against other aspects of usability.

So if make sure these specific entity types mostly behave like nodes, the prototype of entities, then one day we might be able to waive special-casing them in contexts like this one.
Which route should we go? IMHO, we should go both routes: make files, images and terms more similar to other entities, where this makes sense. And in other contexts, such as this one here, keep special-casing them as much as the cognitive model of users requires it. The more of the former, the less of the latter is necessary.

Long post, hope it's still helpful to you. I believe it is... ;)

yoroy’s picture

Thanks Pancho, I think that's a fair summary and the right way forward too.

I need to chew on this a bit more, this whole entities business is pretty abstract. You're right that we have to balance familiarity/mental model with education on how things really work. But applying Field UI in its current state to even more screens, oof :-)

Pancho’s picture

Now that we have a form display tab, the handles for moving fields around were removed, so new fields can't be added in position anyway. This means there is no more reason to stick with the current layout with its space restrictions.

amateescu’s picture

Issue summary: View changes
Status: Active » Closed (duplicate)
Issue tags: -Needs issue summary update