[Plan] Improve field creation experience

Updated issue summary to add #3356894: Make field selection less overwhelming by introducing groups issue for grouping fields

We discussed #3356894: Make field selection less overwhelming by introducing groups at #3380554: Drupal Usability Meeting 2023-08-18. We were surprised that that issue was fixed without a review from the Usability team nor an accessibility review. But I do see that @yoroy marked the issue as RTBC, and he is one of the Usability topic maintainers.

I do not want to lose track of the follow-up issues that were created for #3356894, so I am adding them as related issues here. Is there another public place where they are already tracked? Also, #3356894-59: Make field selection less overwhelming by introducing groups mentions "significant ux regressions". Is there a specific issue to address these regressions?

I have been categorising field types and options and I have one major recommendation:

Rename "Selection list" to "Predefined values" with the term "value" is debatable - options, list...

Reasoning: selection refers to a widget, predefined implies that the options for these field can be hard to edit later.
The counterpart of "prefined" would be "free" - but renaming "text" to "free text" might be excessive even if it would define difference to fe. link (which is special case of text) quite well.

My suggestion would be instead of "Selection list" to have a category "Choice", which would also include "Boolean".
As a site builder, I think of these as similar, and I often wonder "Should I use multiple boolean fields or a single multi-select / checkboxes field with multiple options?".

(I was actually going to create a new issue but this was before I noticed the recent introduction of "Selection list" category)

@donquixote In user testing Boolean didn't got low percentages for grouping so it might be hard to find in any group. I'll tag you in Slack to the thread where the results are visualised. Single item groups were noted as special cases on Friday by the UX meeting but they probably need to be handled under the "Modal" child issue.

Personally I would like to test many-to-many groupings but maybe not now that we are working against a minor release deadline.

#12-14, this is a meta/plan issue, please open a dedicated issue to propose that change.

From #3346682-7: Improve re-use an existing field user experience:

One recommendation I have at this point is that after re-using a field, we redirect the user to the field config form instead of opening it in a modal dialog. We want to move the field config form into a modal dialog but we should do that consistently for all instances where that form is being accessed as part of #2880003: [PP-1] Use modals on the Manage Fields page.

Perhaps the same comment should apply to #3386762: Use modals in field creation and field edit flow. I am adding #2880003: Use modals on the Manage Fields page as a related issue.

I think we should consider the scope of #3386762: Use modals in field creation and field edit flow.

The current MR was opened on 2023-09-13. Several people have done a lot of work on it, but that is a mixed blessing. Right now, it has 177 commits, some of which more-or-less revert earlier work, and that often makes it difficult to resolve merge conflicts. I have already done two non-trivial rebases. I think the MR needs another one now, and I am reluctant to make that effort.

Besides the commit count, it changes 33 files, +922/-610 lines. We have already had a release manager comment on the issue, reminding us of the guidelines in https://www.drupal.org/core/scope. Just the line count makes the current MR very hard to review.

Part of the problem is that the issue's scope is not explained anywhere. The scope is whatever is in the MR. I would like to describe the scope and keep it limited. Then, taking parts of the current MR, I think we can move the issue forward quickly and open follow-up issues for the next steps.

I suggest limiting the scope to the following. For the sake of example, start with the Standard profile.

1. Start on the "Manage fields" page, /admin/structure/types/manage/page/fields. The "Create a new field" link should open in a modal window. Currently it loads the "Add field" form, /admin/structure/types/manage/page/fields/add-field.
2. Choosing a field type, such as Boolean, closes the modal and loads the "Boolean settings for Basic page" form /admin/structure/types/manage/page/add-field/node/field_boolean.
3. Choosing a field group, such as Number, opens a new form in the modal window with the fields from that group. Currently, those fields are added to the "Add field" form. Submitting this form has the same effect as the previous step.

Follow-up issues can address additional UX and a11y reviews, text changes (such as "Add a new field" instead of "Create a new field"), and having more steps happen in the modal window. For that last point, there are already competing suggestions for how to proceed: see my comment here from 2023-12-02, and there is also #3397164: Use modals in field re-use flow.

Re #17,

Thank you @benjifisher for your suggestion related to limiting the scope. I can see the benefits of the new approach you've proposed. This suggestion/approach would have been incredibly helpful for us three months ago.

But as discussed with @lauriii, we've already made significant progress with the current MR that now splitting this issue in multiple issues might result in delay in making further progress.

Perhaps we can:

• Fix whatever feedback we have in the current MR and then open a new MR with latest code(single commit) to make rebase easier.
• Update the IS to cover all the work done in MR.
• Create follow-up for additional UX and a11y reviews.

This is not the first time I have suggested narrowing the scope of #3386762, but my previous comments were on that issue instead of here.

In my opinion, the current MR on that issue should not be merged. The count of changed lines is enough of a reason by itself. The fact that it does too much is also enough of a reason. One of the things it tries to do is address some of the a11y concerns, and there is an active discussion on the issue of how to do that. There is also other outstanding feedback on the MR.

In short, I do not think the issue is as close to "done" as you seem to think it is.

If we make a small, initial step as I suggest, then it does not mean all that effort goes to waste. The MR will still be there for reference, and we can copy useful changes from that MR to new ones.

I added #3408326: Make field selection a two-step form as a child of this issue, and there is now a MR for that issue with passing tests.

As I said in #3386762-46: Use modals in field creation and field edit flow, my advice is

Less is more: move quickly by taking small steps

My point is that #3386762 has been in active development for three months, and it is still not done. Instead of taking small steps, it does a lot of things at once:

1. Split up FieldStorageAddForm into two separate steps.
2. Provide a generic way to load a page into a modal window.
3. Rewrite the markup from #3356894: Make field selection less overwhelming by introducing groups to address the feedback in #3389200: Field selection breaks conventions and increases cognitive load.
4. Put all the pieces together so that adding a new field (or reusing an existing one) is all done in a modal window.

It is not too late to follow that plan, and the work done in #3386762 will not be lost if it is re-used in the individual steps.

Using the same numbering:

1. This is done in #3408326. That issue could have a follow-up to load the two-step form in a modal window. Then "Create a new field" and "Re-use an existing field" would both open in modals, but load the Field Configuration form separately.
2. It would be very easy to extract this from the work done for #3386762.
3. It will be hard to extract this from the current MR for #3386762, but it will be much easier to review after the refactoring in #3408326. We could re-open #3389200.
4. This is an appropriate scope for #3386762. From #3386762-26: Use modals in field creation and field edit flow: that issue should "... focus on one MR to accomplish implementing modals".

There are a few other tasks that could be split off into separate issues. If we want to update any of the input labels, or re-name variables or array keys, that can be done in a separate issue (so that reviewing the other issues is easier). And the recent discussion on #3386762 (the problems with VoiceOver first mentioned in Comment #20 and next in #62) should really be a separate issue. That problem is not created by #3386762: it has been like that since #3356894. I think we might also move the form elements for the field name and label from FieldStorageAddForm to the Field Configuration form.

I just added #3409271: Clean up code in FieldStorageAddForm and related JS as a follow-up to #3408326: Make field selection a two-step form, and I re-opened #3389200: Field selection breaks conventions and increases cognitive load. I am adding these two issues to the issue summary here, along with some other recently opened issues.

I am adding #3409379: Move the first two steps of field creation into a modal. to the list of child issues in the "Proposed resolution".