Don't expose the term 'Entity' to users

Let's fix it everywhere. Tagging for usability review for the strings. Screenshots shortly. :)

In before/after pairs:

Module admin page

(Note: "Reference Field" should be title-cased here; I'll fix that once the strings have been reviewed.)

Manage fields

Field settings

Reference method (instance settings)

Views style selection (creating a new display)

Views administrative listing

-    '#description' => t('The entity type that can be referenced through this field.'),
+    '#description' => t('The type of data this field references.'),

Seems to me this description could just be removed altogether. (Especially if #1953832: Replace 'target type' on entity reference field settings with something clearer improves the title, it shouldn't be necessary.)

I incorporated #4 into #1953832: Replace 'target type' on entity reference field settings with something clearer.

Agreed! I Really love if we could keep this simple.

Rerolled around #1953832: Replace 'target type' on entity reference field settings with something clearer, plus cleaning up the module name and description a little.

Is this RTBC?

Ready from my perspective, if all the string changes look alright.

Hm. If we're going to make such changes, I feel like we really ought to make the API consistent.

--- a/core/modules/entity_reference/entity_reference.info.yml
+++ b/core/modules/entity_reference/entity_reference.info.ymlundefined

@@ -1,5 +1,5 @@
-name: 'Entity reference'
+name: 'Reference Field'

For example, this doesn't make much sense. If we're going to change the name of the module, let's change the name of the module?

+++ b/core/modules/entity_reference/entity_reference.info.yml
+description: 'Provides a field that can reference other items (content, files, taxonomy terms, etc.).'

Also, for the type of people turning on modules, I don't see a reason not to expose that these are "entities" and not nonsense words like "items." For the content type setter-upper, though, that's a bit different.

Can we get a patch here that does nothing other than http://drupal.org/files/manage_fields_after.png ? It feels like the other chances are quite sweeping in nature and I'd rather not hold up a minor wording tweak.

For example, this doesn't make much sense. If we're going to change the name of the module, let's change the name of the module?

How is this any different from, you know, nodes?

Also, for the type of people turning on modules, I don't see a reason not to expose that these are "entities" and not nonsense words like "items." For the content type setter-upper, though, that's a bit different.

I disagree. The first time someone uses Drupal, one of the first things that person does is look at the modules page to see what functionality is available. For that person, the current module name and description are incomprehensible.

Edit: Also, really, "entity" is the nonsense word here to normal people. "Item" is self-explanatory. At D7 launch, "entity" made me think of this:
http://www.treknews.net/wp-content/uploads/2012/07/star-trek-tng-bluray-...

Also, changing it on the field page but NOT the module page is a serious WTF, because there's then no relationship between the field and the module that provides it. I don't think we can do one without the other.

The name of node.module is Node. It's a totally different thing than naming entity_reference.module "Reference Field." And while "node" is a nonsense word that never means "a blog or a poll," thus somewhat justyfing a 1984-esque ban on calling things what they actually are, an "Entity" is an actual standard term in Entity-Relationship modelling, which is what you're doing when you're defining your data model for your site. Like with Taxonomy, I don't see a compelling reason to obfuscate this to end users; I'd much rather handle explaining this concept with Tour module than conflating with a generic noun that effectively means nothing.

If we want to rename the entire module to "Reference," then let's do that. But then that means renaming it wholesale, not making the UI and the API inconsistent with each other.

@webchick,
totally agree with you. I think changing the title doesn't add a lot to usability.
For developers used to 'entity reference' label and module this will be also unfamiliar and will vice versa reduce the usability. So the changes are not critical (from my point of view), and should be changed if there's a certain need for that.

I agree with amateescu - IMO entity-reference (the module name) is the exact term: It's referencing of entities.

This is probably wontfix then, because I think changing the field name in the dropdown but not in the module label doesn't make any sense.

That also probably means #1847596: Remove Taxonomy term reference field in favor of Entity reference needs to wait on a solution for #1847590: Fix UX of entity reference field type selection. That's probably better in the long run in any case.

FWIW, I still think expecting end users to know what "Entity" means is setting ourselves up for failure, but D8 usability testing will show that (and we then fix it) or it won't (and then we don't).

I would completely agree with xjm. Entity is a very abstract term, probably not as abstract as node - but still expecting our very wide range of site builders to know about entity-relationship modelling sounds very risky. This can and will be tested in time.

So...

in order to do some usability testing, we could still get a patch ready here that takes the word Entity out of the UI.
It's really easy to set up a link to simplytest.me that we can give to participants in a usability study.

Updating the issue summary to make the point we are waiting to decide what to do pending results. Are we thinking that May might be a good time to gather that info?

Portland might be a great opportunity to do some UX testing on ER. If at all possible, though, we should try to unblock the taxonomy field conversion patch as much as possible, since it has lots of implications for fields in general.

I'll try to split out some less controversial changes.

I am a little afraid we might be over extending our resources and attention, on such a small part. If its bad I am sure we will notice once we test the field UI, I am a little afraid we are setting up for a biased study if its done at Drupalcon and/or through people that we know. I just wanna avoid you all spend a lot of time on something, that can easily be tweaked and setup a possibly biased study. I'd vote for just implementing the proposed idea, we don't have to validate every tiny detail that would require way to much resources.

I intend before release, to do a more full study on Drupal and with that include a bunch of the changes we made during clean up.

I'm not so sure about Entity being that bad.

We have two modules now that expose the concept of Entities to users. Entity translation and Entity reference. Entity translation was renamed to Content translation, but that's somewhat misleading, as we usually mean nodes if we use "content" in the UI.

So IMHO, we do need a term for "all the things you can reference/translate" with those modules. Content IMHO doesn't work and e.g. just "Reference" also might be problematic, as you can't reference *everything*.

Re-roll : Discussion aside, #7 did not apply to HEAD.

add info about the latest proposed resolution being more sweeping.

To be honest in general I'm not sure whether exposing the term 'Entity' is such a bad thing.

1. Users already potentially think about content in a generic way, more than its current incarnation in nodes. They probably think users as content as well potentially, if its rendered somehow as part of the page
2. Users aren't stupid. Empowering them by explaining them a bit more how things are under the hood, for example by exposing those words, is kind of a recon.
3. While it might be horrible in some user targeted distributions, it is potential acceptable because Drupal core kinda seems to target the site builder mostly, which should be better aware of some of the underlying structures.

Postponing until the UX team can take a look.