Field selection breaks conventions and increases cognitive load

I am adding #3356894: Make field selection less overwhelming by introducing groups as a related issue and making this one a child of #3346539: [Plan] Improve field creation experience.

Let's mark this as a duplicate to #3386762: Use modals in field creation and field edit flow. We can reopen this if this doesn't get addressed by that issue.

I think that #3386762: Use modals in field creation and field edit flow was poorly scoped, and trying to address these points in that issue was a mistake. I am re-opening this issue and adding it to the issue summary of #3346539: [Plan] Improve field creation experience.

So going for something similar on #3386762: Use modals in field creation and field edit flow, without the modal for now.

Is this ticket still valid after #3408326: Make field selection a two-step form?

I think we should update the issue summary to remove the parts that have been addressed by #3408326: Make field selection a two-step form.

Just for issue summary,

Side note all the work being done around the fields has been fantastic!

Tested it locally and works as expected. The screenshots needs to be updated in IS as the field selection is a two step form now.

Think this will need usability review

But I find it very odd/annoying that clicking on any item auto takes me to the 2nd form. So I have to continuous click back if I clicked the wrong field.

But will leave for others to review.

Hi, Verified and tested the current changes on Branch 11.x version.
Followed the below testing steps:
1. Install the Drupal version 11.x
2. Fetch current branch
3. Create content type as landing page
4. Create a new field
5. select any field
6. Observe the changes on next page
Taking reference from #26 comment,
Usability i have observed here:
1. In this form (first step)select/choose field option should be there on each fields, user might get confuse here: admin/structure/types/manage/test_landing_page/fields/add-field
2. Its better to have one step form.
Attaching screenshot for reference:
keeping it to Needs review state.
Thanks!

After selecting a field when user goes to next page and clicks `back` button, user goes to field section page which is correct, but if now user refresh the page by submitting the url again, it goes to next page, which does not seems correct to me.

Also IS can be updated as per implemented functionality.

Last commit will only work for node entity, but it will throw exception in case of other entities like block, taxonomy etc.

The incorporation of a "Back" button in step 2 has enhanced usability. I have tested it for various content types, and it appears to be functioning as anticipated.

Overall looks good to me. I think unnecessary changes can be reverted.

During my local testing, I observed that when adding a new field and being redirected to the field form after selecting the field type, the URL includes a query parameter, for example ?entity_type=node , in case of the content types. This query parameter is actually necessary ?

Thank you.

It is not passed explicitly if you look at the route $path/fields/add-field/{new_storage_type} in core/modules/field_ui/src/Routing/RouteSubscriber.php I think it's just visible now because of passing the extra parameter while calling this route, easy fix just pushing now.

The changes look good to me. Marking as RTBC. However, a usability review might still be required.

Grayed out and reduced font as suggested.

Hi,
Verified and tested the MR 5869 on the Drupal 11.x version.

Testing steps:

1. Install the Drupal version 11.x
2. Go to the Structure->content types-> manage any content type
3. Create a new field
4. select any field
5. Observed Add field for state 1 and step 2
6. Apply Patch, and checked

Test Result:
Add field's step two font is updated as mentioned in #41; Label text and description text font is as same form step one.

Attaching screenshots for reference

Moving to RTBC

@Kanchan Bhogade:

Thanks for the new screenshots, and for explicitly reviewing the changes made in response to Comment #41.

It would help to add the new screenshots to the issue summary. I am adding the issue tag for that.

This issue still needs an accessibility review, so it is too early for RTBC. I am adding an item to the "Remaining tasks" section of the issue summary to remind people of that.

So the changes here turn the radio elements into links. In order to make that change accessible it would be necessary to:

• Remove the <form> element. By changing these to links, it is now semantically incorrect as it is a form with no form elements (but in issue #3386762, these would open modals and could be buttons instead... and could still live inside a form)
• The links need to be styled as links. If clicking something takes you to a new page, the appearance should be consistent with the other elements that would take the user to another page. (but....... in issue #3386762, these would open modals and could be buttons and retain their styling)

The changes needed to make the changes in THIS issue accessible would effectively be unnecessary once #3386762 lands. Those same changes would also make #3386762 more difficult to land as it would require undoing much of that work to get back to where HEAD is. I can think of three possible approaches to navigating this:

• Include modal support in this issue instead of #3386762. However, I think that was the originally intended approach and there were objections to it so I'm not sure how feasible that is.
• Make the changes listed above to make THIS issue accessible, and accept that it will add complexity to #3386762 (open in modals)
• Approach this issue as if #3386762 will land (make the options buttons within a fieldset), but commit to reverting the changes here before the next release if it turns out #3386762 can't make it in. I'm not opposed to this approach... but I'm concerned that there's no formal policy in place to ensure the revert happens. What is here is acceptable as an intermediate step, but is not acceptable to release. (maybe there's a way to only commit to 11.x and disallow addition to 10.x until #3386762 is there as well?)

Okay so it does not make much sense to get this in and not the modals , @benjifisher what do you think?, can we merge #3409379: Move the first two steps of field creation into a modal. ((which was rebased on top of this issue hence might seem like a lot of changes but it's not)), here it won't be too much to review or too many changes in one MR and it seems to be the fastest and the most efficient way forward.

It still dictates the links and the content inside, is it still an accessibility issue ? Uploaded a sample video voiceover_field_selection.mov

It still dictates the links and the content inside, is it still an accessibility issue ?

Afraid so, just because a screenreader can see it does not mean it's correctly categorized/conveyed. Two issues is that they are contained in a <form> with no form elements, and they are not logicially grouped - they're just seen as individual links where it's not immediately clear that they represent a single choice within a group of options.

I am trying to get them in quick succession instead the modals issue is mostly sorted out #3409379: Move the first two steps of field creation into a modal..

I think it's reasonable to complete this issue with the intent to complete #3409379: Move the first two steps of field creation into a modal. before the next minor release, otherwise we revert. Doing this successfully will demonstrate that we can be a bit more incremental than our current cadence, and my hope is that can increase innovation momentum in Drupal. If the followup doesn't make it in it will demonstrate that such an approach is unwise to do in the future, so lets be sure to avoid that and show we can handle a bit more flexibility.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Split into controller and form. So we have no forms without form elements.

Split into controller and form. So we have no forms without form elements.

Nice work @omkar.podey. While this won't be fully accessible until we land #3386762: Use modals in field creation and field edit flow, the changes that are best done within this issue's scope are addressed so I'll remove the tag. This will still require a broader code review but unless there are major changes the A11y is all set.

Just to clarify this #3386762: Use modals in field creation and field edit flow isn't going to go in at all the issue had a lot changes at once and hence it was split up into smaller pieces that could go in independently.

The new split up issues are -

1. #3408738: Create a new OpenModalDialogWithUrl command
2. #3409379: Move the first two steps of field creation into a modal.
3. #3397711: Move label and machine name fields to the field config edit form
4. #3389200: Field selection breaks conventions and increases cognitive load
5. #3408326: Make field selection a two-step form

more to be added as these get in.

FYI. The function field_ui_form_field_ui_field_storage_add_form_alter() still exists in the code after #3356894: Make field selection less overwhelming by introducing groups.
Atm this is a dead code cuz the behaviour/logic was changed.
Since this ticket is in fact a continuation of that epic, it is the best candidate to remove this useless function.

Updated MR.

May need a rebase but Unit and Javascript tests failed.

Left feedback on MR

This looks much cleaner, but the order of the fields still has no recognizable structure, thereby making it difficult to find the right field type.

For example, if you install Commerce module in addition to core. In the previous dropdown all Commerce fields were grouped together but now they are random scattered over the grid.

Also even with the decluttered cards, the grid is difficult to scan especially when you have contrib modules (like Commerce) installed and you end up with some 30 field types, spread over 3 or 4 columns

Changes that would make it easier to find field types could be
- to add a filter field (similar to on the modules page),
- grouping fields by again (at least if they are provided by a contrib module),
- and allowing users to switch to displaying the fields in a list rather then an a grid, because that's easier to scan.

Screenshot of a site with Commerce module installed.

Added reference to #3459265: [PP-1] Add the ability to filter by field type when creating a new field that might be a good approach to work in parallel.