Formerly titled "The options under the Add field drop-down describe the data you want to store, but the user was imagining the widget it would produce".

During the usability sessions, some participants struggled to figure out how to add fields. For example, they where given the task to add a select box to choose from available countries. As the field UI asks for the data type first, without knowledge of the way that Drupal stores field data it was hard to find out that "List (text)" was the data type to choose.

Dropdown (initial)
Dropdown (next)

Checkbox/ radio Select list Autocomplete Autocomplete (tags style) Date and time Text Textarea (multiple rows) Bespoke (Hidden)
Boolean Tick - - - - - - - Tick
Comments - - - - - - - Tick (comments) Tick
Date - Tick - - Tick - - - Tick
Email - - - - - - - Tick (email) Tick
Link - - - - - - - Tick (link) Tick
List (float) Tick Tick - - - - - - Tick
List (integer) Tick Tick - - - - - - Tick
Number (decimal) - - - - - Tick - - Tick
Number (float) - - - - - Tick - - Tick
Number (integer) - - - - - Tick - - Tick
Content Tick Tick Tick Tick - - - - x
File - - - - - - - Tick (file) Tick
Image - - - - - - - Tick (image) Tick
Taxonomy term Tick Tick Tick Tick - - - - Tick
User Tick Tick Tick Tick - - - - Tick
Text (plain, long) - - - - - - Tick - Tick
Text (formatted, long, with summary) - - - - - - - Tick (with a summary) Tick
List (text) Tick Tick - - - - - - Tick
Text (formatted) - - - - - - Tick - Tick
Text (formatted, long) - - - - - - Tick - Tick
Text (plain) - - - - - - - Tick (textfield) Tick
TOTAL 7 7 3 3 1 3 3 7 21

Proposed resolution

Add a visual UI to cover the 80% use case and make it as easy as possible to add a field, for the more advanced users or the exceptional fields, link to the current UI.

Remaining tasks

- Decide which fields are in the 80%
- Decide which settings they need
- Provide a thumbnail, label and description for each

User interface changes

- A new UI will be added and will be the entry point for "Add a field", we can add an option so the site admin can decide which UI is the default one

API changes


Data model changes



dasjo’s picture

Just creating this ticket, as I have seen lewis nyman's presentation at DrupalCamp North:

Lewis mentioned that a quick-fix might be working on the terminology & structure of the options being presented when selecting the data type. A long-term solution could be putting selecting the intended widget first as part of a form builder in a later release of Drupal. It was also mentioned that the Views add dialog could help add more context information to the options a user can select from.

While a form builder is pretty far away, I think it might be helpful let the user choose an intended widget first and explain then the different options for selecting data types based on that.

Let's have a discussion about what's good, what can be implemented soon & where we wanna go the long-run :)

vickytnz’s picture

Issue summary: View changes

Added more detailed information about the issue (and the full list of the fields to demonstrate the problem - it's pretty apparent when you look the complexity)

vickytnz’s picture

Issue summary: View changes
vickytnz’s picture

Added screenshots of current problem page

vickytnz’s picture

Issue summary: View changes

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

attiks’s picture

Proof of concept to find an easier way to add fields to entities,

Only label, description, required needs to be filled in, afterwards user selects what type of fields he/she wants to create, but the options are human readable.

Single line of text and multiple lines do not have extra options, they will be created using the default options.

Selecting 'radio buttons', gives the user 3 new options

1. enter data manually

2. select an existing vocabulary, or create a new one

3. use an entity reference

After clicking create the field gets created and attached to the entity (not in code yet!) and user gets a message with a link to all relevant settings pages so he/she can alter the defaults.

All feedback appreciated

yoroy’s picture

Woohoo! Great, thanks for working on this. Tagging to keep it on the radar.

attiks’s picture

To clarify the reasoning behind #7, it's mainly based on question our clients have when they have to add a field, even after explaining most tend to forget how to do it.

I've added description in the form, but most of the time the client does not use it, although it should be better if they do. But following the 80% rule it might be removed.

Same goes for the required, so basically only label has to stay.

The linked code is dummy, so don't expect the module to do anything, once there's a consensus if this is the way to handle the problem, code will be added.

attiks’s picture

Quick update, module now actually is doing something, if you want to test, use the git version, you'll see a new action "Quickly add a field", make sure to enter the label in lowercase as if it is a machine name, and select single or multiline text

attiks’s picture

I've created a small demo video,

attiks’s picture

Uploaded a new video to demonstrating the creation of a new vocabulary and adding an entity reference field all at once.

The module is now complete as an MVP, so next would be to decide how to proceed, either in contrib or in core. The main benefit of doing it in core is that we can extend the current field plugins, in contrib we need to create our own.

Bojhan’s picture

Wondering, what if we represent the current "radio's" as images. Showing the actual widget?

attiks’s picture

Might work, or we render the real widget as a preview, somebody in Twitter said it might be handy.

We also need to differentiate between plain text and formatted text, will work more on this during Drupal dev days

Bojhan’s picture

@attiks The reason I think images might be more suitable is 1) you can't interact with them, making it less confusing. 2) You don't have to "mimic" a sensible representation choosing relevant options, 3) you don't have to account for "hijacking" of the styles from other themes or plugins.

I would happily provide the relevant images.

yoroy’s picture

Issue tags: +DevDaysMilan
Bojhan’s picture

23.74 KB

What about representing it as the following:

options dreamfields

I can provide the separate fields as images.

amateescu’s picture

@Bojhan, the problem with presenting form elements as images is that the actual form elements might look different based on each user's OS / browser combination. Or do you think that's not such a big concern?

Bojhan’s picture

@amateescu The reason we display an image is exactly that. Because themes can decide themselves to completely overwrite how this looks. By using images, we avoid potential confusion between labeling and what themes do. People might be confused by the fact that your widgets are interactive, when in fact you select the "way of displaying" and you can choose more sensible options using an image. I think its a well weighted decision to go with images, obviously there are cons - but similar to representing layout with images, its a more manageable and controllable way of representing options.

attiks’s picture

#18, #19 I'm also in favor of using images, using real HTML might be tricky because it will be rendered using the admin theme, so that implies we need to render part of the page using the front-end theme, which will be tricky, and probably not even realistic in the end.

If/when we find a decent way to tackle this, we can still add it later.

#17 I like the images, clean and simple. The multiple lines of text is rich text, no idea if we can make it clear in the image, but not even really sure if it needs to be in the image.

attiks’s picture

Bojhan’s picture

There you go :) I think this is all actually.

Bojhan’s picture

We can probably make formatting clear by making a part "bold" and one without? But lets try this first.

attiks’s picture

Issue summary: View changes
94.58 KB

#22 Code adjusted to support this, we probably need some more preview images for radio buttons and maybe for the link field.

Code can be found in the use_image_options branch, I had to create a custom render element for radios, but the current code is not that clear, but it works.

Css will need some love as well before going live.

attiks’s picture

Issue summary: View changes
77.16 KB

Changed the layout to 4 columns, and hide the Create field button until the user selected something

Bojhan’s picture

Lets sit next to each other to optimize the CSS.

Bojhan’s picture

This needs more review and initial coordination with product manager to ensure this is viable for Core.

attiks’s picture

New screenshot, added date (datetime) field and optimized the css

Branch is merge into 8.x-1.x, and tagged a new alpha

webchick’s picture

Ok, so first off, 1000x YES. This is a HUGE step toward making Field UI far more approachable for mere mortals!

However, I guess I worry a bit about the implementation, so tagging for framework manager review. This works fine for core, because we know ahead of time what all of the field types are. But:

- Contrib is extensible, and includes fields such as Media, Field Group, Address Field, Geofield, etc. In other words, more complex, multipart fields. Will they be similarly able to inject themselves into this UI?
- Is an image of the field the right way to go here? And what's the default if one isn't specified? (Which it won't be, for any contrib field module until they add whatever annotation key to specify a preview image.)
- We already do have a "preview" of sorts on the configuration screen, when you go to set the default value of the widget (we noticed at the UMN test that people would remark "Oh, finally, a preview!") .. would simply outputting the widget with some defaults be the better way to go, so that it shows exactly as it will in your browser / theme? (I guess I don't get the concern about having to show fields in the front-end theme. Most forms are done in the admin theme, no?)

Then from the product management side, it would help to know what happens when you click one of those options (like how do you specify you want radios, but with numeric vs. text storage?)

attiks’s picture

#29 Thanks

1/ It's plugin based, so contrib can easily add their own

2/ The idea of the image was to show something mortals might recognize, for the moment there's no default, but we could add a placeholder or make the preview image (set using annotation) mandatory

3/ Outputting real HTML might be doable for simple elements, but no idea how good it will work for the more complex fields, or for generic fields like an entity reference. The remark about the front end theme is something we ran into in a couple of projects, but all of those were more like web apps for authenticated users, not a regular website.

Not all combinations of field type, storage and widget are available, this is aiming for the 80% use case, so - for instance - all the lists will use text storage if the user chooses to add there own values, see screenshot. For the more advanced or rarely used fields, we would link to the current form in some way. This solution also does not allow you to re-use a field, the idea was to let the current form handle it, but we might be able to add it.

Another remark from this afternoon was that using checkboxes/radio buttons is not advisable for linking to content, so we still have to add the autocomplete entityreference.

Screenshot of the extra options after selecting 'List of checkboxes'

attiks’s picture

Quick update

- dependency code moved to plugin manager
- added number
- added hover with description

attiks’s picture

Entity reference added

Next step:

- provide a default image?
- use real HTML preview
- decide what should be shown on this screen
- add a link to the 'old' add a field page for advanced users
- ..

attiks’s picture

#29, @amateescu

Screenshot using the rendered edit widget, don't look at the styling for now, but not sure if it's a good idea to do it like this, for instance the image fields shows a file upload field, I assume an image makes more sense, but then we'll start to mix edit widget and rendered elements

attiks’s picture

New screenshot, code lives in use_real_demo

attiks’s picture

FYI: Adding support for other modules is as easy as adding the following plugin (used address as an example)


 * @file
 * Add an address.

namespace Drupal\dream_fields\Plugin\DreamField;

 * Plugin implementation of 'address'.
 * @DreamField(
 *   id = "address",
 *   label = @Translation("Address"),
 *   description = @Translation("This will add an input field for an address and will be outputted using the defaults."),
 *   preview_provider = "dream_fields",
 *   provider = "address",
 *   preview = "images/textfield-dreamfields.png",
 *   field_types = {
 *     "address"
 *   },
 * )
class DreamFieldAddress extends \Drupal\dream_fields\DreamFieldPluginBase {

   * {@inheritdoc}
  public function saveForm($label, $required, $values, $entityTypeId, $bundle) {
    $this->field_name = $this->createFieldMachineName($label);
    $this->widget_id = 'address_default';
    $this->entityTypeId = $entityTypeId;
    $this->bundle = $bundle;

    $this->field_storage_values = [
      'type' => 'address',

    $this->field_values = [
      'label' => $label,
      'required' => $required,

    $this->field_display_values = [
      'label' => 'above',



ifrik’s picture

Could this be done as a contrib module first to test it?

My first impression is that it will require a lot of scrolling around given that we already have about 15 fields as a minimum in core, and more through contrib.
In some cases, we either might need two such fields or explain users what kind of configuration they can expect after choosing such a field. For example: How will people know that the Date field can be used with or without time? (Obviously, that's not clear in the current drop-down list either, but that does not give people a WYSIWYG-feeling anyway.)

Another quick fix for the problem could be in to change the label from "Add new field" to something like "Add a field to input...". This would already give a bit more context for now.
Some of the individual fields could already be changed now as well, even as they were already changed between D7 and D8.

attiks’s picture

#36 Thanks for the feedback

1/ It's in contrib now, but the easiest way to test this on a large scale is to do it as an experimental module

2/ The idea is to only show some fields (and some configurations) to cover to 80% use case, most site builders are only using some fields and probably always with the same options, a single line of text will mostly be plain text, multiple lines will mostly be formatted text. If this UI will show more then 15-20 options, it will be confusing again for mortals. The main problem is that there are to many options and since the current UI is storage based, some are unclear.

attiks’s picture

#36 Regarding the date options, we could change:

The label to "Date and time"
The description to "Add a field to store the date and optionally the time"

attiks’s picture

Issue summary: View changes
attiks’s picture

Issue summary: View changes
webchick’s picture

Mmmm. Fewer words are better. :) I think if someone sees a field called "Date time" and only wants date, but no other fields present themselves as anything remotely "date-y" they'll pick the closest option and then discover from there that they can hide the time part.

webchick’s picture

Btw, the rationale for not using the actual widget does make sense. This would allow the icon for Entity Reference to show an autocomplete field with an "a" typed in and then showing a drop-down for "1: About Us" below or whatever, which would indeed be very tricky to pull off if it was just an autocomplete field sitting there. Also means only one new annotation property (or whatever) vs. multiple. We do need to keep it optional, though; we can't break BC of existing field types by introducing a new required property.

attiks’s picture

#41 You're probably right, it's a bit hard for me to come up with good labels, let alone a good description.

Did any of the user testing perhaps showed which fields people tried to use to solve a particular use case?

attiks’s picture

#43 The annotation is on a new plugin so there's nothing we can break, we cannot re-use the fields since they don't map 1-to-1

BTW: Good idea on how to present the autocomplete, @Bojhan do you have time to build it, if not I ask my frontender to have a look at it tomorrow.

ifrik’s picture

If this UI will show more then 15-20 options, it will be confusing again for mortals.

in #37

Unfortunately, with just a few contrib modules we will get to 15 and more options soon. The last screenshot already shows 12 options. Add comments as a core field, and then for example fields provided by Media and Paragraphs, or by a geo-module. Media will need different options for a file you upload directly (like an image or a pdf) and one that you link to (like a Youtube video) because thinking from widgets these are different. Geo fields will most likely need two different for widgets where the user types in an address, or where a map is displayed.
So keeping this scalable beyond core seems a real challenge.

ifrik’s picture

Thinking further along the lines of the initial issue: Users indeed do not need to know how the data of a field is stored in the database, but the current dropdown menu asks them to take a decision based on that.

Could we split this up into two steps? First asking users what the field should contain: Text, list of options, links, files, etc. - and then present the user a second list that narrows down the options.
That might be similar to a workflow that theses Wysiwig fields offer, but without the additional question of how this will fit on a page.

attiks’s picture

Could we split this up into two steps? First asking users what the field should contain: Text, list of options, links, files, etc. - and then present the user a second list that narrows down the options

This is what this module is doing

vbouchet’s picture

Why not to create an admin interface where we can select the field which should appear in this new UI. Then we can add a "View more" tile with a specific permission "Create advanced fields" which would display all the other field type. By doing this, we can give access to complex fields to contributor with the technical background or we can decide to have a limited list of fields for newbie.

Some tile should probably be updated to reflect more the purpose of the field (placeholder for example) but it is only experimental for now ;-)

webchick’s picture

Reviewed in-depth with the other core committers today. In general, massive +1 to the proposed change, ideally completely replacing the old UI rather than offering an alternative, since it's superior in almost every way. :)

The big concern from both the framework + release managers though was that we're not guiding users to make good decisions regarding storage, and instead short-handing it. And those non-optimal storage decisions will persist even after the experimental module is uninstalled, as they cannot be changed after the field is created.

Because, the screen after clicking on one of the widgets on the big overview screen looks like this (for example):

Checkbox selection

"Manually enter data" means you get "List (text)," always. Even if you enter 1, 2, 3, 4 as choices. So we do need the ability to select storage here, as well.

Also, we talk about vocabularies here, but new users will have no idea what a "vocabulary" is yet. In general, by listing references underneath the widgets, you eliminate one of the big wins of Drupal which is that references are "first-class citizens" that can actually take a number of different widgets, not just autocomplete.

@alexpott's suggestion was to add a second button at the top of "admin/structure/types/manage/article/fields" to "Add reference" ("Quickly add field" which is currently there would just replace "Add field"), which re-shows more or less the same widget selection as "Add field" does. This would both solve the above problem and also promotes a really awesome differentiating feature of Drupal.

webchick’s picture

For now, product manager review is done. Feel free to re-add the tag when the next iteration is in a reviewable state.

attiks’s picture

we're not guiding users to make good decisions regarding storage, and instead short-handing it

There will be no easy way to guide a non-technical person to make that decision, most have no clue what is the best to use.

Agree that we need to promote the use of references (especially terms), so maybe we can add the order and start with vocabulary (changing the text so it explains the benefits of using a vocabulary) and move the 'enter data manually' to the bottom.

@alexpott's suggestion was to add a second button at the top of "admin/structure/types/manage/article/fields" to "Add reference" ("Quickly add field" which is currently there would just replace "Add field")

Great idea, will update #2755097: UI changes

attiks’s picture

Had another look at all the tiles we have right now, most are fine regarding storage options.

1/ Lists (radio, checkbox, select) are a potential problem if there's a lot of data, in the case that people fill in the options by hand we can detect if they fill in a lot (50+) and offer them the option to use a vocabulary, if they agree we can create the vocabulary and convert all entered options to terms.

2/ Using an existing vocabulary with lots (500+) of terms, we can suggest they use an autocomplete field and switch the widget if they agree.

3/ For text fields we already assume plain text for single line text fields and rich text for multi line text.

For small lists (which is probably covering the 80% use case) it doesn't really matter what they choose, the performance penalty will be minimal. Probably for 80% of the sites is the storage options are not going to be problematic.

My main concern is that we will end up with too many options and hence confuse people.

Proposal to move this forward:
- Do the UI changes as explained in #49
- Move 'Enter data manually' to the bottom
- Explain the word 'vocabulary' inline
- Do the changes explained in this comment

PS: Will try to catch up with Gabor today at drupalaton

catch’s picture

if they agree we can create the vocabulary and convert all entered options to terms.

This would be a nice option in the taxonomy admin interface, I've often missed it.

I think a lot of #52 is solved by the separate tab (and maybe making that the primary tab) as well moving 'enter data manually' down to the bottom. For me things like vocabulary length, number of items in a list etc. would be non-blocking follow-ups - those aren't creating new issues for me compared to the issue pointed out in #49.

There's also situations like say US states or British counties where people often make an explicit choice to keep them as text, but the list would be quite long.

Apart from that I really like this patch, I think we can remove the framework manager review tab at least until there's a version incorporating #49.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

attiks’s picture

attiks’s picture

Moved "Enter data manually" to the bottom

attiks’s picture

Issue tags: +Dublin2016
attiks’s picture

#49 Will look into the implications of "we're not guiding users to make good decisions regarding storage"

attiks’s picture

52.26 KB
62.21 KB

Number looks like this, so storage is fine

I changed the code for the lists, and switched storage to list_integer if all keys/values are numeric, not sure if we need to support list (float)

Anything I missed @webchick, @xjm

Bojhan’s picture

Issue tags: -Needs usability review

Lets get product review here first, honestly not sure why it's not happening.

tkoleary’s picture


Perhaps because this is not in the ideas queue? IMO it really belongs there.

Bojhan’s picture

Yhea, it makes sense to move it.

attiks’s picture

Project: Drupal core » Drupal core ideas
Version: 8.2.x-dev »
Component: field_ui.module » Idea

Moving ...

tkoleary’s picture

Title: The options under the Add field drop-down describe the data you want to store, but the user was imagining the widget it would produce » Provide users with a visual way to understand and build content types (dream fields) as an experimental module.
tkoleary’s picture

Issue summary: View changes
tkoleary’s picture

Status: Active » Reviewed & tested by the community

As an idea I think this more than meets the definition of done and its hard to question it's value to site builders.

attiks’s picture

#49 UI changes are done, only discussion point left is how to handle huge lists.

As said in #53 "There's also situations like say US states or British counties where people often make an explicit choice to keep them as text, but the list would be quite long."

So this basically means we have different ways to tackle this

1/ List is short (less than 20 items) are stored as text

Problem is we have no way of knowing the list is final, maybe it's extended later by the site builder, so maybe always allow the user to convert a list to a vocabulary.

2/ If the list is longer we provide an option to convert it to a vocabulary (explaining why) or keep it as a list to handle the example in #53, so maybe we should merge "Create a new vocabulary" and "Enter data manually", so the user can enter values and after entering the values he/she is presented with an option to store it as field data or terms.

3/ If the user enters key values, and all of them are integer do we store the list as a list of integers?
If we follow the approach in 2, this will become a special case, we can add javascript that scans the keys and inform the user that this list can be stores as a list of integers. If the user agrees (by checking a checkbox) we store it as a list of integers.

If the above is discussed and we have consensus, I can start updating the code.

attiks’s picture

Alternative UI: When a user selects to create a new vocabulary, we give him/her the option to enter the terms right away.

Wim Leers’s picture

Select which data you want to provide

I think a clearer wording would be: Select which list options you want to provide. And then "Enter list options manually" instead of "Enter data manually".

Other than that, I like #68 a lot.

attiks’s picture

Quick feedback from UI meeting


1/ select widget
2/ selet data type

- Date: add select date/date time/ ts
- add support for boolean
- file upload
- add weight to plugin to sort

"Add reference"

- same ui
- same workflow
- add support for fields without a plugin

attiks’s picture

Assigned: Unassigned » attiks
attiks’s picture

Issue summary: View changes
55.71 KB

Quick update:

- Screen is split in 2 parts both using tiles
- Lists is appearing on both screens
- Tile added to link to a user