Field selection breaks conventions and increases cognitive load

Here is a rough example how to use proximity to connect type and options (the extra large "boolean" is an unintended side product)

I am adding ✨ Make field selection less overwhelming by introducing groups Fixed as a related issue and making this one a child of 🌱 [Plan] Improve field creation experience Active .

This is expected to be fixed by https://www.drupal.org/project/drupal/issues/3386762 ✨ Use modals in field creation and field edit flow Needs work

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

I think that ✨ Use modals in field creation and field edit flow Needs work 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 🌱 [Plan] Improve field creation experience Active .

So going for something similar on ✨ Use modals in field creation and field edit flow Needs work , without the modal for now.

omkar.podey → changed the visibility of the branch 3389200-field-selection-breaks to hidden.

omkar.podey → changed the visibility of the branch 3389200-field-selection-breaks to active.

kunal.sachdev → made their first commit to this issue’s fork.

Is this ticket still valid after 📌 Make field selection a two-step form Fixed ?

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

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 there is no option available to select/ click the field, user might get confuse here: admin/structure/types/manage/test_landing_page/fields/add-field
2. Its fine to make two step form because it look more specified but to select any field the radio button option should be there.
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, such as ?entity_type=node , specifically for the content type. 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 the new compulsory parameter {new_storage_type} and as it's being used in calling the route field_ui.field_storage_config_add_sub_$entity_type_id.

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

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2024-01-05 Active . That issue will have a link to a recording of the meeting.

For the record, the attendees at today's usability meeting were @AaronMcHale, @benjifisher, @emma-horrell @rkoller, @shaal and @simohell.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

The MR addresses the main points of the issue. Visual presentation has been improved. Some of the usability problems present in the current MR are being addressed by other issues and seen as out of scope for this issue. Keyboard navigation was tested roughly and the MR improves it's usability.

This issue would benefit from separate accessibility review.

Requested change

A small change request is to make description texts in both form steps visually consistent. At selecting the field type description is smaller that the label and in a dark grey colour. Selecting the option for field type uses same style for both the option text and the description. It is recommended to use same styles for text in both steps: larger text for label/option and a bit smaller maybe dark grey for description (like in the first step).

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 📌 Move the first two steps of field creation into a modal. Needs work ((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 📌 Move the first two steps of field creation into a modal. Needs work .

I think it's reasonable to complete this issue with the intent to complete 📌 Move the first two steps of field creation into a modal. Needs work 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 ✨ Use modals in field creation and field edit flow Needs work , 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 ✨ Use modals in field creation and field edit flow Needs work 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.

FYI. The function field_ui_form_field_ui_field_storage_add_form_alter() still exists in the code after ✨ Make field selection less overwhelming by introducing groups Fixed .
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