Spin-off from #1847590: Fix UX of entity reference field type selection. In comment 7 of that issue, amateescu suggested:

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

That issue has moved in another direction, but I think this idea could be useful regardless, and for more than just the ER field type(s).

If you currently install Drupal HEAD and enable all field type modules, you get 18 options for "Select a field type":

- Boolean
- Date
- Decimal
- E-mail
- Entity Reference
- File
- Float
- Image
- Integer
- Link
- List (float)
- List (integer)
- List (text)
- Long text
- Long text and summary
- Telephone number
- Term reference
- Text

What if we replaced this with an initial select containing:

- Boolean
- Date
- E-mail
- File...
- Link
- Number...
- Reference...
- Telephone
- Text...

A top-level selection of "File..." would open up a second Select right next to it containing:

- File
- Image

A top-level selection of "Number..." would open up:

- Decimal
- Float
- Integer
- List (float)
- List (integer)

A top-level selection of "Reference..." would open up:

- Comment
- Content
- Term
- User
(plus others TBD)

A top-level selection of "Text..." would open up:

- List (text)
- Long text
- Long text and summary
- Text

Notes:

  • Especially in the case of the secondary select for "Text...", I think the alphabetical ordering results in an unfortunate order, but let's ignore that in this issue. I also think the "List (*)" labels are confusing, because you're not creating a list, you're creating whatever type is in the parens, and then just restricting the content author to select from a preset list of options, but again, that's a preexisting condition of HEAD that can be discussed in a separate issue.
  • Above, I put File and Image into a File group and Term into the Reference group. That's partially based on #1847590-14: Fix UX of entity reference field type selection, though what to do about Term might need more discussion.
  • In terms of implementation, my current assumption is that the final selection corresponds to a distinct field type. So to implement the "Reference..." grouping would require that each entity type reference is a derivative plugin (sub-field-type), per #1847590-3: Fix UX of entity reference field type selection. So, the groupings is just a UI suggestion, not something that requires any deep changes in Field API. Perhaps just a hook to allow modules to define/alter the groups.
Files: 
CommentFileSizeAuthor
#16 drupal_core_fieldui-optgroup.png163.13 KBChris Charlton

Comments

amateescu’s picture

Maybe this should be implemented at the Field API level, not only in the UI, by adding a 'group' or 'parent' property to field type definitions. This way, the existing alter hooks can be used instead of introducing a new one.

The rationale for the above, considering that Entity reference field types become plugin derivatives, is that we need a simple way to check if a field type is an entity reference field (not having to do a stripos() check on the plugin id), so we can solve two problems at once.

Bojhan’s picture

Version: 8.x-dev » 9.x-dev

If you did any research into how to make this accessible, then its D8 material. But so far I just see an idea, real late in the cycle that requires a lot of work

effulgentsia’s picture

Version: 9.x-dev » 8.x-dev

If you did any research into how to make this accessible, then its D8 material.

We can render the HTML as a single Select and use <optgroup> for the groupings. Maybe that's even enough, or maybe, for people with JS enabled, we can use JS to replace that single Select with two Selects. Other than needing a nojs fallback, what are the accessibility concerns of hierarchical selects?

klonos’s picture

+1 for fixing this in D8.

Bojhan’s picture

@effulgentsia I have had many many discussions with the a11y team over the years to get anything like hierarchal select in core, I suggest we reach out to them again to get this feedback. There are many, probably even more important places where we can use hierarchal select to make things more usable.

effulgentsia’s picture

Issue tags: +accessibility

Ok, let's start with an issue tag. What are the other use cases you're thinking of? http://drupal.org/project/hierarchical_select does a lot, and I'm not necessarily suggesting we bring in all of it: this issue is a very minimal use case.

Wim Leers’s picture

As the maintainer of the Hierarchical Select module, I very much advise against using it in core in its current form. It's *way* too flexible and consequently way too complex.

A simplified version of it should be sufficient indeed.

EDIT: but it's important to then clearly delineate what exactly the feature set and behaviors should be. Please look at http://wimleers.com/demo/hierarchical-select/config-ui to get a grasp on which parameters are inherent to the "hierarchical select" concept.

mgifford’s picture

Issue tags: +aria

There are some simple accessibility problems in both Hierarchical Select #1764128: Accessibility - Missing Labels and your demo Wim (just run it through the Webaim WAVE Toolbar).

We'd certainly want to involve ARIA in this though as content seems to be added to the screen after the page has loaded.

David_Rothstein’s picture

Besides the fact that it would be really ugly for people with JavaScript turned off, is there any reason not to simply use #states for this instead?

David_Rothstein’s picture

Above, I put File and Image into a File group and Term into the Reference group. That's partially based on #1847590-14: Fix UX of entity reference field type selection, though what to do about Term might need more discussion.

Yes, it's not obvious that people know to look under Reference for Terms... Similarly, it's not obvious that people know to look for Image under File. (In fact I believe that's one of the reasons File and Image fields were kept separate in Drupal 7 rather than merged together.)

yched’s picture

Similarly, it's not obvious that people know to look for Image under File. In fact I believe that's one of the reasons File and Image fields were kept separate in Drupal 7 rather than merged together

Not sure about that. Even before cognitive considerations, there was a technical reason : File and Image fields have a different set of widgets and mostly formatters. Different set of eligible widgets & formatters means different field types.

This is still true currently in HEAD, and is also part of the equation for "one single entity_reference field" vs "one distinct field type per target entity type". The former currently means they all have the exact same collection of widgets and formatters. No way to have a widget specific to image files.

klonos’s picture

How about we make the drop-down a bit wider and include merged options that actually give a clear hint about most common variants. Like so:

Number (Decimal/Float/Integer)
File/Image/Video
Reference to Content/Users/Terms etc
Text/List

David_Rothstein’s picture

@yched, I believe splitting Image from File was a combination of both reasons (technical and user experience). In fact, it looks like you started that discussion yourself :) #560780-6: Add Image Field to image.module

Wim Leers’s picture

#9: #states doesn't scale. Hierarchical Select does. As Bojhan alludes to in #5: there are many use cases in core, the most archetypical one I believe is selecting a menu item in the menu tree (#191360: Scalable menu selector). That potentially contains tens of thousands of menu items, and loading each level on demand instead of generating a megabyte of HTML is preferable in that case.
However, if we limit ourselves to "small scale" trees, say up to 100 items, then #states is a great idea: very little new code :) I'm not sure how accessible that would be though.

mgifford’s picture

Version: 8.0.x-dev » 8.1.x-dev
Status: Active » Postponed

I'm assuming this should get bumped to 8.1.x.

Chris Charlton’s picture

Or at least <optgroup> groupings. Pretty, pretty please! :)

optgroup usage in field_ui

Note: screenshot is manipulated.

mgifford’s picture

Issue tags: +html5, +optgroup

Probably too late for D8.0

mgifford’s picture

Status: Postponed » Active
amateescu’s picture

David_Rothstein’s picture

Status: Closed (duplicate) » Active

That did not introduce a hiearchical select - it is still just one big dropdown (though it is now organized by optgroups).

However I might lean towards "won't fix" on this, given that it could introduce usability problems also (see #10), although #12 is an idea for how to address that.

Wim Leers’s picture

+1 for temptation to "won't fix" this. I don't think a Hierarchical Select will be fundamentally better than the current optgroup approach. Discoverability will likely be worse with a Hierarchical Select.

webchick’s picture

It's worth pointing out that the current optgroup approach tested incredibly poorly at the UMN UX testing. "Boolean" is the first option in the list (one participant even Googled it as a result since "it must be important"), and the most common option (Text) is near the very bottom of the list. It's likely that because Hierarchical Select would reduce the level of scanning required (with core alone there are 30+ options in that list, let alone with contrib), it could be a marked improvement over the status quo, so I wouldn't be so quick to won't fix this, personally.

Wim Leers’s picture

But a Hierarchical Select itself has usability downsides too:

  • it's a non-standard UI concept, it may not be clear to all users how it even works, scaring them away before they even start
  • even worse discoverability (How do I know what will be in the second or third level? Especially if the top-level terminology is meaningless to me.)
  • works poorly without JavaScript

(Note I say these things as the author of https://www.drupal.org/project/hierarchical_select.)


I think what would be much more valuable is if we showed a live preview of the corresponding default widget, because that shows the user what that input would look like. I suspect that'd actually even be less effort.

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.

tkoleary’s picture

Issue tags: +Usability, +UMN 2015, +sprint

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.