Adapt field type labels after switch to multi-step field creation

Created on 13 May 2025, 2 days ago

Problem/Motivation

After ✨ Make field selection less overwhelming by introducing groups Fixed the field type labels only appear after having previously selected a field type category. With this flow the current labels are awkwardly worded. For example, after just having chosen that you want to add a Number field, the two options you are presented with are Number (integer) and Number (decimal). The relevant information that you need to decide on in this step is the part in the parenthesis while the main word of the label is completely redundant at this point.

The field type labels for text and list fields are similarly awkward.

Proposed resolution

Update the field labels. See below.

Remaining tasks

User interface changes

Plain text fields

Formatted text fields

(See 🌱 [Meta] Deprecate text_with_summary Active about the related issue of deprecating the text with summary field type)

Number fields

(Note that this screenshot was taken on Drupal 10.4. In Drupal 11 the float field type does not appear due to πŸ“Œ Move Float fields to contrib Active )

Selection list fields

(See above for the note regarding the float list.)

Introduced terminology

-

API changes

-

Data model changes

-

Release notes snippet

πŸ“Œ Task
Status

Active

Version

11.0 πŸ”₯

Component

user interface text

Created by

πŸ‡©πŸ‡ͺGermany tstoeckler Essen, Germany

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

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

  • Needs usability review

    Used to alert the usability topic maintainer(s) that an issue significantly affects (or has the potential to affect) the usability of Drupal, and their signoff is needed. When adding this tag, make it easy to review the issue. Make sure the issue summary describes the problem and the proposed solution. Screenshots usually help a lot! To get sign-off on issues with the "Needs usability review" tag, post about them in the #ux channel on Drupal Slack, and/or attend a UX meeting to demo the patch and get direct feedback from designers/UX folks/product management on next steps. If an issue represents a significant new feature, UI change, or change to the general "user experience" of Drupal, use Needs product manager review instead. See the scope of responsibilities for product managers.

Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @tstoeckler
  • Merge request !12110Change field types labels β†’ (Open) created by tstoeckler
  • πŸ‡©πŸ‡ͺGermany tstoeckler Essen, Germany

    Updating proposed resolution

  • Pipeline finished with Failed
    2 days ago
    Total: 578s
    #495946
  • Pipeline finished with Success
    2 days ago
    Total: 377s
    #495983
  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    As much of some of these would make sense I may be a -1 for such as change as it would be very disruptive

  • πŸ‡©πŸ‡ͺGermany tstoeckler Essen, Germany

    Hmmm... can you elaborate? Not sure what you're getting at specifically.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    I mean you had to alter tests for this to pass, which could break contrib modules.
    Sure a lot of drupal docs, user manuals, and training will have to be written with these changes.

  • πŸ‡©πŸ‡ͺGermany tstoeckler Essen, Germany

    Well we "just" switched the entire form from a single massive select field to an elaborate multi-step workflow, so I'm a bit baffled why now adapting the labels to fit into that new workflow vs. the old select list is somehow disruptive in the context of the larger change.

Production build 0.71.5 2024