As part of #3343940: Field UI 2023 User Research we discovered some issues with the experience of re-using a field. Users found it unclear when they could re-use an existing field, versus creating a new field. Many of the users considered re-using a field more like a "clone field" feature. But even when users knew how the feature works, it was hard for them to figure out whether they actually could re-use a field, because this depends on the pre-existing field storage configuration.
We gave users an example case where we told them that it was possible to reference articles from basic page but we would also like to reference articles from recipes content type. An additional requirement we presented was that with this field, it should be possible to reference 3 articles. Some of the expert users were able to deploy several workarounds to figuring out if they could use the field, but for the less experienced users it wasn't clear how they would be able to verify whether they could re-use the field. We prompted some of them to look at the "Field List" feature where they would be able to find the necessary information.
Because of this, we implemented a prototype for a new re-use existing field experience as part of #3346539: [Plan] Improve field creation experience. This was well received, and given similar tasks, users were able to determine whether they could re-use a field.
Since it isn't feasible to display all of the necessary information on the current select list, the proposed solution is to implement a new view for re-using a field. The view should display critical information about the field storage configuration. Some of the information can be collected from #2458127: Show field/field-storage summary instead of field type on field listings. This helps users to quickly locate and use the fields without navigating to the field list page.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | reuse-field.gif | 148.72 KB | ckrina |
| #10 | Screen Shot 2023-04-04 at 11.40.18 AM.png | 117 KB | hooroomoo |
| re-use-existing-field.png | 150.08 KB | lauriii |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !3662changes, plain diff MR !3647
Comments
Comment #2
lauriiiComment #7
lauriiiThe progress is looking really solid. 🤩 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: Use modals on the Manage Fields page.
Comment #9
hooroomooremoved wrong srceenshot
Comment #10
hooroomooComment #11
hooroomooComment #12
lauriiiFew comments:
/admin/structure/types/manage/page/fields/add-field. This probably requires refactoring some tests but will also make sure that we have sufficient test coverage for the new UI.Comment #13
hooroomooComment #14
smustgrave commentedTested on a standard install of 10.1.x
Went into the manage field for the Basic page content type
Verified button Re-use an existing field
Clicking it showed the fields from the Article content type which the basic page doesn't have
Selected a field and it was added just fine.
Clicked button again and list updated as expected.
Accessibility tested
When modal opens focus goes to search box
Tabbing stays within the modal and follows logic path.
Comment #15
lauriiiPosted feedback on the MR. 😇
Comment #16
ckrinaI was testing this and I have 2 concerns:
1. What should be the label or description ("Filter by field or field type") is used as a placeholder. I understand this is trying to save space, but it is usually discouraged to use a placeholder like this because you loose that meaningful information once you start entering info. I'd suggest moving it into a label.
2. The search box doesn't work, it's not filtering.
Comment #17
lauriii#16.1 This is implementing a pre-existing pattern from
/admin/modules. Do you think it would be acceptable to open a follow-up issue to revisit this pattern and fix it for all instances of this?Comment #18
hooroomooComment #19
lauriiiFew more comments on the MR
Comment #21
lauriiiI hope the CI will be 🟢 now 😅
Comment #22
smustgrave commentedSeems to have a test failure.
Comment #23
tim.plunkettThis commit broke
\Drupal\Tests\field_ui\FunctionalJavascript\ManageFieldsTest::testFilterInReuseFormbecause it is still trying to use the HTML IDs that were removedComment #24
lauriiiFixed tests and added some minor fixes. Hoping that CI remains 🟢 🤣
Comment #25
tim.plunkettEverything works as expected, and this has pretty good code coverage.
@lauriii, @bnjmnm, and I had a quick discussion on "Re-use" vs "Reuse", and this MR matches what other UI strings do (with the hyphen), so if there's a desire to standardize on "Reuse" that should be opened as a follow-up.
Comment #27
bnjmnmAfter many rounds of feedback, this change looks like it's ready to go into core. This is a UX improvement I've been hoping to see for many years and happy to be the one committing it to 10.1.x.
Comment #28
longwaveTagging as a possible highlight for the release, UX improvements are always welcome.
Comment #30
ressaThe new design is great, thanks! I wanted to try it, and thought something was wrong: I opened the Article "Manage fields" and there was no "Re-use an existing field" button ... for logical reasons. So I created #3423197: Alert that no fields can be re-used?.