Follow-up post: Dream Fields for Drupal 8 - part 2

I went to Drupalcon NOLA and was looking for a new way to contribute, since there've been a lot of discussion about the front-end part, and after reading @dries blog post Turning Drupal outside-in I started looking at the field UI. I stumbled upon the core issue 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 and decided that the outside-in approach might be a good approach.

We have some clients that from time to time add a field to an existing content type, we explained them how they should do it and they understand it. We tell them to ignore a lot of things appearing on the screen.

So after a quick talk with Roy I started to build a Proof of Concept (PoC) or Minimum Viable Product (MVP) on Monday to investigate if it might work codewise. The first version was a completely mocked version, it had all the options hard-coded, but it did show that it might work.

On Tuesday and Wednesday I created two short videos showing how the interface might behave, and after another talk with Roy, I decided to start refactoring.

So by Thursday most of the field types were added and working. On Friday I attended the core sprints and had a quick talk with @dries, where we decided to start this in contrib, so it would be easy to move to experimental in 8.2 or 8.3

By Friday evening all logic was converted to custom plugins, so any module can easily add their own fields.

Since I had to leave on Saturday, I spent some time in the airport and on the plane to refine the code. So when I arrived home on Sunday, I pushed the first alpha version, which looks like this

Since writing code to solve this is only a small part of the solution, we need to decide on the next steps.

Which fields to show

To avoid information overflow we need to limit the list to 10 options at the most, so this means we as a community have to decide which fields needs to be included.

For each type we have to define the following:

• the label
• a good short description in human language
• the storage settings
• the widget settings
• the display settings (default)

Change the output, so the - optional - settings of a field are closer to the radio button. This will also allow us to use a better description field.

() Single line
   Description and maybe an example of when to use this option.
() Image
   Description and maybe an example of when to use this option.
     Image options
() List of checkboxes
   Description and maybe an example of when to use this option.
     Checkbox settings
() Multiple lines of text

Other ideas for fields

• create an image and specify the output width, the code will create an image style on the fly.
• add an internal link.
• add an external link.
• add an hero image, output will use responsive images if enabled, otherwise will fall back to normal image.

How to decide what options to show

AFAIK there are no known numbers of how many fields are used on an average site, and how they are configured. We could write a module (another one) to gather those statistics, or create a survey asking people which kind of fields they use, but it should contain questions like "An multi value image field with the image linked to the content"