Field selection breaks conventions and increases cognitive load

Created on 22 September 2023, 5 months ago
Updated 13 February 2024, 18 days ago

Problem/Motivation

New version of field creation adds unnecessary clutter to the form and increases cognitive load for using the form. ThIs version also breaks conventions on basic html elements. With some changes the form's usability can be easily improved.

Cognitive (gestalt) principles involved are similarity, proximity and same container. The principles are known to take precedence by similarity being overridden by proximity and proximity overridden by same container.

Radio buttons

Radio buttons are based on similarity and proximity. When a radio buttons are placed far away from each other and especially if separated into visual containers the brain will not understand them to be related. Thus here they add visual clutter and cognitive strain by not matching familiar patterns.

Overlapping options to be addressed in a follow-up ๐Ÿ“Œ "Selection list" should be removed from field types and given as an option for "number" and "plain text" Active

Field types are not well defined and hiding the options details makes user unable to select the correct type without toggling between types to read the options descriptions. Especially selection list overlaps with plain text and number. For end user "selection list" is a display widget for contend that is either text, number or reference.

Steps to reproduce

Proposed resolution

  1. Radio buttons should never be used unless they are aligned vertically.
    • Just visually hide the radio buttons and use the whole box to highlight the hover or selected item.
    • Instead of using input for field type, consider using HTML summary or html_tag for type and details containing radiobuttons for options. If we must have input value for type, then consider using hidden and set the correct one based on selected option. This should be logically possible because of the hierarchy/cadinality of types vs options.
  2. Increase the attention value of selected type and its option to form a group that is recognized as strongly connected items. This could be achieved by proximity (display options next to the selected type) or strong similarity (shape, color), this is eliminated with the use of the two step form as the second step makes a focused sub option approach.
  3. "Selection list" should be removed from field types and given as an option for "number" and "plain text" (would be addressed later in a follow up ๐Ÿ“Œ "Selection list" should be removed from field types and given as an option for "number" and "plain text" Active )

Text content for descriptions should be reviewed in a separate task.

Remaining tasks

  1. Accessibility review

User interface changes

API changes

Data model changes

Release notes snippet

๐Ÿ“Œ Task
Status

Needs review

Version

11.0 ๐Ÿ”ฅ

Component
Fieldย  โ†’

Last updated about 8 hours ago

Created by

๐Ÿ‡ซ๐Ÿ‡ฎFinland simohell

Live updates comments and jobs are added and updated live.
  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

  • Needs accessibility review

    Used to alert the accessibility topic maintainer(s) that an issue significantly affects (or has the potential to affect) the accessibility of Drupal, and their signoff is needed (see the governance policy draft for more information). Useful links: Drupal's accessibility standards, the Drupal Core accessibility gate.

Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @simohell
  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland simohell
  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland simohell
  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland simohell

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

  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland simohell
  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland simohell
  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland simohell
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States benjifisher Boston area

    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 .

  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland simohell

    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

  • Status changed to Closed: duplicate 4 months ago
  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

    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.

  • Status changed to Active 3 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States benjifisher Boston area

    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 .

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia omkar.podey

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

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia omkar.podey

    omkar.podey โ†’ changed the visibility of the branch 3389200-field-selection-breaks to hidden.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia omkar.podey

    omkar.podey โ†’ changed the visibility of the branch 3389200-field-selection-breaks to active.

  • Assigned to omkar.podey
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia kunal.sachdev

    kunal.sachdev โ†’ made their first commit to this issueโ€™s fork.

  • Pipeline finished with Failed
    2 months ago
    Total: 602s
    #66204
  • Pipeline finished with Success
    2 months ago
    Total: 616s
    #66212
  • Issue was unassigned.
  • Status changed to Needs review 2 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States smustgrave

    Is this ticket still valid after ๐Ÿ“Œ Make field selection a two-step form Fixed ?

  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland lauriii Finland

    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 .

  • Pipeline finished with Success
    2 months ago
    Total: 1060s
    #66409
  • Pipeline finished with Success
    2 months ago
    Total: 662s
    #66428
  • Status changed to Needs work 2 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States smustgrave

    Just for issue summary,

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

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia kunal.sachdev

    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.

  • Pipeline finished with Success
    2 months ago
    Total: 657s
    #66688
  • Status changed to Needs review 2 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States smustgrave

    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.

  • Pipeline finished with Failed
    2 months ago
    Total: 311s
    #67367
  • Pipeline finished with Success
    2 months ago
    #67409
  • Pipeline finished with Success
    2 months ago
    Total: 625s
    #67443
  • Assigned to DishaKatariya
  • Issue was unassigned.
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia DishaKatariya

    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!

  • Status changed to Needs work 2 months ago
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia narendraR Jaipur, India

    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.

  • Pipeline finished with Success
    2 months ago
    Total: 584s
    #68363
  • Status changed to Needs review 2 months ago
  • Status changed to Needs work 2 months ago
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia narendraR Jaipur, India

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

  • Pipeline finished with Success
    2 months ago
    Total: 646s
    #68427
  • Status changed to Needs review 2 months ago
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia Prashant.c Dharamshala

    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.

  • Status changed to Needs work 2 months ago
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia narendraR Jaipur, India

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

  • Pipeline finished with Failed
    2 months ago
    Total: 564s
    #68965
  • Pipeline finished with Success
    2 months ago
    Total: 508s
    #69024
  • Status changed to Needs review 2 months ago
  • Pipeline finished with Canceled
    2 months ago
    Total: 261s
    #69070
  • Pipeline finished with Canceled
    2 months ago
    Total: 319s
    #69072
  • Pipeline finished with Success
    2 months ago
    Total: 515s
    #69074
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia Prashant.c Dharamshala

    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.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia omkar.podey

    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.

  • Pipeline finished with Success
    2 months ago
    Total: 560s
    #69110
  • Pipeline finished with Failed
    2 months ago
    Total: 167s
    #69458
  • Pipeline finished with Success
    2 months ago
    Total: 566s
    #69462
  • Status changed to RTBC 2 months ago
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia narendraR Jaipur, India

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

  • Status changed to Needs work about 2 months ago
  • ๐Ÿ‡ซ๐Ÿ‡ฎFinland simohell

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

  • Pipeline finished with Success
    about 2 months ago
    Total: 553s
    #73346
  • Status changed to Needs review about 2 months ago
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia omkar.podey

    Grayed out and reduced font as suggested.

  • Assigned to Kanchan Bhogade
  • Issue was unassigned.
  • Status changed to RTBC about 2 months ago
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia Kanchan Bhogade

    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

  • Status changed to Needs review about 2 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States benjifisher Boston area

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

  • Status changed to Needs work 25 days ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States bnjmnm Ann Arbor, MI

    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?)
  • Pipeline finished with Failed
    25 days ago
    Total: 172s
    #89303
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia omkar.podey

    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.

  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia omkar.podey

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

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States bnjmnm Ann Arbor, MI

    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.

  • Pipeline finished with Failed
    20 days ago
    Total: 167s
    #92670
  • Pipeline finished with Failed
    20 days ago
    Total: 673s
    #92685
  • Pipeline finished with Success
    20 days ago
    Total: 481s
    #92729
  • Status changed to Needs review 19 days ago
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia omkar.podey

    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 .

  • Status changed to Needs work 19 days ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States bnjmnm Ann Arbor, MI

    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.

  • Pipeline finished with Failed
    19 days ago
    Total: 173s
    #93620
  • Pipeline finished with Success
    19 days ago
    Total: 2220s
    #93621
  • Status changed to Needs review 18 days ago
Production build https://api.contrib.social 0.61.6-2-g546bc20