Replace "Select a field type" with a hierarchical select

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.

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

+1 for fixing this in D8.

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

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.

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.

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?

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

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.

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

@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

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

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

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

Note: screenshot is manipulated.

Probably too late for D8.0

This was done in #1963340: Change field UI so that adding a field is a separate task and #2373491: Categorize field type plugins.

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.

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

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.

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.

Tagging for https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html

We have implemented similar but slightly different solution in #3356894: Make field selection less overwhelming by introducing groups. I think this is essentially now a duplicate of that.