Problem/Motivation

The field UI is really hard to use. Everyone knows it's a problem, but no one is actively working on it (no open issues). Let's revisit!
#521468: Redesign content type editing (after CCK UI is in)

Discussion around the field UI redesign stopped in 2009, but was happening over here:
UI-oriented summary of D7 Field API

Related issues for Drupal 8:
Scotch: Blocks & Layouts Everywhere Initiative
D8 UX Analysis: Design Assumptions and Principles
D8 UX Analysis – Layouts, IA Spaces and the Principle of Definition-Usage Pairs

Let's also keep in mind that the "display fields" tab may end up being replaced by Scotch / templates / something else - but we'll still need the add fields tab, and it still needs a lot of improvement!

Proposed resolution

This whole process probably needs a redesign from the ground up. Some frustrating things about the current system that could use to be changed in the new system (if not replaced entirely) are as follows:
- add step numbers to the process of adding a field so users know when they are "done"
- remove page 2 of the multi-step form, since the "questions" asked there are repeated on page 3
- send users to the display fields interface when they are done adding a field (not back to the add field screen)

Remaining tasks

- Design
- Implementation

User interface changes

Content Builder, step 1

Content Builder, step 2

Content Builder, step 3

Content Builder, step 4

API changes

- unknown

Comments

jenlampton’s picture

Issue summary:View changes

suggest total redesign

jenlampton’s picture

Issue summary:View changes

more about display fields tab

jenlampton’s picture

Attached is an example of how I actually want to build content. I've excluded the layout part of "display settings" since that will need to belong to scotch, but here's how I want to add and configure my fields (which, by the way, should not be called fields!)

After people get through step 4, they should be redirected to (step 5?) the layout manager - where they can position the element on the "page".

yoroy’s picture

What I get from these is that we need multi-step forms to help people through picking and configuring individual fields, which is definately something we want to provide as a pattern.

swentel’s picture

The form builder approach is also outlined in #1472348: Fields UI improvements using form builder pattern - not sure yet which one to mark duplicate so we can focus in one issue.

klonos’s picture

Version:9.x-dev» 8.x-dev
Category:feature» task
Priority:Major» Normal

Very interesting!

...uploading the pdf files from #1 as images. All credits to Jennifer.

[Edit: moved images to issue summary]

...

klonos’s picture

Issue summary:View changes

link to D7 redesign issue

klonos’s picture

Issue summary:View changes

...screenshots of the proposed changes.

webchick’s picture

Version:8.x-dev» 9.x-dev
Category:task» feature

Don't really see this happening in D8 anymore.

webchick’s picture

Priority:Normal» Major

However, it's a pretty sub-optimal screen as far as UX is concerned, so escalating to major.

klonos’s picture

...the screenshots were not attached back in #5 for some reason :/

webchick’s picture

As further anecdotal evidence of how much this actively bites actual users of Drupal, I gave a Spark session at DrupalCon Austin and spent the last 30 minutes in a big messy group prioritization exercise, where everyone in attendance (maybe 80-100 people) could shout out pain points for site builders (among other questions) and then everyone got two "votes" (hand raises) as we went through the list, which I then tried to eyeball and stick in some kind of order. Here are the full results for those who are curious: http://www.slideshare.net/webchickenator/spark-authoring-experience-in-d... (slides 32+)

When we got to "Point and click form design," almost every single hand shot up in the room. While I can't say for sure who was there, and what their specific backgrounds were, it's safe to assume it was a good mix of both big site and small site builders, some content authors, etc. So while we can't by rights make this a critical issue, since you can still build a form even if it is painful, I'm extremely open to the idea of introducing something in minor releases of Drupal 8 that make this much, much easier for site builders to use.

webchick’s picture

Priority:Normal» Major
swentel’s picture

@webchick I guess #1963340: Change field UI so that adding a field is a separate task is one little step - but has been stalled now for a while.

swentel’s picture

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

Might be for 8.1.x

webchick’s picture

Status:Active» Postponed

Yep.

effulgentsia’s picture

#2651660: Investigate where and how a frontend framework could be used is a newly opened issue that references this one.

Related, I argued in #2645666-54: [policy, no patch] Require Node.js for Drupal 9 core and rewrite some of Drupal's UI code from PHP to JS that Field UI might be a good candidate to refactor to an SPA (single page app).

As an example of why I think that, I installed Standard profile, then deleted the Article content type, and then went to see how many steps it would take to re-create its fields along with form mode and display modes. Here's what I found.

Once I create the Article type itself, then I go to /admin/structure/types/manage/article/fields, and from there ("FPR" = full page refresh, "AS" = ajax submission):

Add 3 fields (Image, Tags, Comments). For each:

- "Add field" -> FPR -> fill in form
- "Save and continue" -> FPR -> fill in form
- "Save field settings" -> FPR -> fill in form
- "Save settings" -> FPR -> back to field list

Configure form mode:

- "Manage form display" -> FPR -> drag fields to correct order
- For Tags, select "Autocomplete (Tags style)" -> AS -> verify settings are correct
- "Save" -> FPR -> back to form display

Configure display modes:

- "Manage display" -> FPR -> drag fields to correct order
- For Image, click gear icon to change settings -> AS -> select "Large"
- "Update" -> AS -> back to display
- "Save" -> FPR -> back to display
- "Teaser" -> FPR -> drag fields to correct order
- For Image, click gear icon to change settings -> AS -> select "Medium"
- "Update" -> AS -> back to display
- For Tags, change Format to "Label" -> AS
- For Tags, click gear icon to change settings -> AS -> select "Link label to the referenced entity"
- "Update" -> AS -> back to display
- "Save" -> FPR -> back to display
- "Default" -> FPR -> Expand "Custom Display Settings", select "RSS"
- "Save" -> FPR -> back to display
- "RSS" -> FPR -> drag fields to correct order
- "Save" -> FPR -> back to display

So in total, this process required 22 full page refreshes and 8 ajax submissions, for a total of 30 times being blocked on a round trip to the server.

Incidentally, 30 doesn't include the total number of round trips, because some of those FPRs actually involve 2 round trips (form submission followed by redirect to a GET URL) and the "drag fields to correct order" includes a non-blocking AJAX submission to the server for every single field reordering operation (I don't know why we do that).

Seems to me that this whole experience would feel better if it were all an SPA (from the point I arrive on /admin/structure/types/manage/article/fields), without a single blocked-on-server interaction. But that would require refactoring some of our current PHP code for Field UI (including configuration forms for field types, widgets, and formatters) to JavaScript, which is what I'm arguing for in #2645666: [policy, no patch] Require Node.js for Drupal 9 core and rewrite some of Drupal's UI code from PHP to JS.

When we got to "Point and click form design," almost every single hand shot up in the room.

A point-and-click form design might not require this to be a client-rendered SPA. It might be possible to implement something nice with all server-rendered responses to AJAX submissions. But for various reasons, I think it would be easier and more natural to implement it as a client-rendered SPA using a modern JS framework, if and when we have the tooling necessary to support that (such as a framework picked, client-side Twig rendering integrated with that framework, and the aforementioned configuration forms implemented in JS). Therefore, it might be an interesting project to prototype such an implementation as part of the exploration for issues like #2651660: Investigate where and how a frontend framework could be used, #2645250: [META] Supersede Backbone in core admin UIs with a new client-side framework, and #2645666: [policy, no patch] Require Node.js for Drupal 9 core and rewrite some of Drupal's UI code from PHP to JS.

catch’s picture

Refactoring that workflow to be a single page app wouldn't by itself address the usability issues that Dries mentions in http://buytaert.net/turning-drupal-outside-in though.

I used the very first version of CCK with Drupal 4.7, nearly ten years ago, and I still get tripped up by it.

For example I recently on a Drupal 7 client project added a 'Text' field instead of 'Text (long)' by accident, and only realised when I went to the node form and saw a text field instead of a textarea. Then I had to go back to field UI, delete and recreate the field.

Had the interface been more 'formbuilder-ish' (that's not explicitly mentioned in the blog post, but it's the closest model we have in core and it's been discussed in relation to field UI for years now) I would have selected a textarea directly.

And in that particular case, there's a 1-1 relationship between the textarea widget and text (long) so I'd never have had to make an explicit choice for the data type at all. That's assuming we presented the summary widget as a separate option.

That inversion immediately would have removed an entire step/decision for the user as well as a couple of server round trips.

However for something like a select list, text field, checkboxes, radios we run into trouble, because:

- exactly the same widget may be used for different field types (file upload for file vs. image fields)
- the same form element might be used for different widgets (entity reference select list vs. list text select)

An attempt at a new field UI really ought to deal with these issues. Even if we end up requiring data-type selection first before any mention of widgets/formatters, that needs to be an explicit choice and not just inherited from the status-quo.

But for various reasons, I think it would be easier and more natural

But that would require refactoring some of our current PHP code for Field UI (including configuration forms for field types, widgets, and formatters) to JavaScript

I really have trouble with the juxtaposition of those two sentences. Also I've already posted on that issue that many, many interface elements in field UI - such as the configuration form for entity reference fields, image formatter settings and etc. depend on information that can only be obtained by a round trip to the server. So the idea that nothing would ever be blocked on the server is an exaggeration of the possibilities of client-side rendering - not to mention all the up-front weight of loading the SPA in the first request.

Wim Leers’s picture

Had the interface been more 'formbuilder-ish' (that's not explicitly mentioned in the blog post, but it's the closest model we have in core and it's been discussed in relation to field UI for years now) I would have selected a textarea directly.

However for something like a select list, text field, checkboxes, radios we run into trouble, because:

How about this very easy, very fast-to-implement intermediate step that AFAICT would improve things considerably: when selecting a field type, automatically preview the corresponding widget.

That would roughly look like this:

(Prototype hacked together; patch for prototype attached.)

jonathanjfshaw’s picture

Status:Postponed» Active
dawehner’s picture

Afaik the contrib module https://www.drupal.org/project/field_ui_ajax basically tries to solve the same problem.

tic2000’s picture

Afaik the contrib module https://www.drupal.org/project/field_ui_ajax basically tries to solve the same problem.

Not yet. In version 1.0, which is almost finished, the goal is just to have everything Field UI provides to be ajaxified. Which at least will address what @effulgentsia talks about in #14. What is left to be done for 1.0 is the adding view and form displays, which will be finished in a couple of days at most.

But for a version 1.1 (the weird versioning is cause I try to match "major version" with core since I can't release a 8.1-1.x, 8.1-2.x, 8.2-1.x etc, only 8.x-1.x) I want to do something similar to what the IS describes, or what @Wim Leers shows in #16.

I'm open to suggestions and want to "fast iterate" on ways of presenting the add field workflow until we find something that works and is widely accepted.

Wim Leers’s picture

@tic2000++, yay for Intellix for sponsoring @tic2000's time!

yched’s picture

@catch's #15 summarizes perfectly what makes a form-builder approach to Field UI difficult :

- exactly the same widget may be used for different field types (file upload for file vs. image fields)
- the same form element might be used for different widgets (entity reference select list vs. list text select)

@Wim #16 / widget preview :

Could be a nice 1st step indeed - a couple challenges though :

- Which one of the available widgets do we present ? the one that's specified as 'default' for the field type ?
- A widget needs an actual FieldItemList object to display itself, which in turn needs an actual entity. It's probably doable to build a fake runtime entity with a random value for the field, we do that for the "default value" input IIRC - plus in D8 field types have a method to generate a sample value, that could help too I guess.
At that point in time though, none of the field / field storage settings have been configured yet, so this fake, runtime FieldItemList would necessarily use the default settings
- For some widgets, having the widget around and "active" in that form might produce weird / unwanted behaviors. E.g a file upload widget, what if the user actually picks a file ? Or other widgets with ajax stuff or side effect. That's kind of case-by-case, but "being able to output a harmless sample version" is currently not part of the Widget contract (Interface)

Wim Leers’s picture

the one that's specified as 'default' for the field type ?

Yes.

A widget needs an actual FieldItemList object to display itself, which in turn needs an actual entity. […] runtime FieldItemList would necessarily use the default settings

I wanted to build a more complete prototype, but that's exactly the problem I ran into. I figured out that that needed to happen, but I don't know this component well enough to quickly do that. Good to see that confirmed.

E.g a file upload widget, what if the user actually picks a file ?

Two options:

  1. #disabled => TRUE, but that also makes it feel bizarre
  2. Some very nasty tricks like overlay a div/iframe on top of the widget that intercepts all clicks :P
catch’s picture

Adding to those two options:

3. Additional interface for widgets that lets them specify a demonstration with dummy content.
4. Some way of associating icons with widgets.

jonathanjfshaw’s picture

@Catch's #23 point #4, icons for widgets, is an interesting good long term direction, it enables a variety of solutions.

However, I think the idea of showing the default widget is not necessarily a usability advance. It actually increases the confusion when the default is not what you want. The user would then have to think to themselves "well I want radio buttons but I pick the one that shows a select list because I know that's just the default and I can change that later ...". It might be sometimes more confusing for novice sitebuilders than the current UI.

yched’s picture

3. Additional interface for widgets that lets them specify a demonstration with dummy content.

The DX risk there is that we don't want to ask widget authors to duplicate the code of their Widget::formElement() method in a new sampleFormElement() method. Even if separate for a BC's sake, the new method would have to call the existing one with an optional "$sample = false" param.

4. Some way of associating icons with widgets.

Yeah, thought about that too, but :
- if we're talking about a screencap, it seems like it could produce a lot of visual inconsistencies (margin around the actual widget in the screencap, theme, browser-specific rendering...) - and translation... so that sounds like a no-go
- otherwise, we're talking about actual icons (abstract, language/browser/theme-agnostic visual representation of the "idea behind the widget"), and that sounds like asking a lot of design/UX ability from contrib authors - plus, inconsistencies as well

2. Some very nasty tricks like overlay a div/iframe on top of the widget that intercepts all clicks :P

nasty / non-super-bulletproof, but easy / handy :-)

almaudoh’s picture

So, speaking of "outside-in" instead of "inside-out", using the example of creating a new document or spreadsheet using your favorite text editor or spreadsheet application. The document is always created first, then the other stuff are added.

Why not look at the entirely different approach of a prototyped entity (or dummy entity or blank entity) of that entity type. This prototype can be created and cached whenever a new entity type is created. We could even have a class method like ::getPrototype() or something that allows you to get a fully initialized instance of the Entity class. Then it becomes easier to do stuff with that.

tic2000’s picture

3. Additional interface for widgets that lets them specify a demonstration with dummy content.

That was my idea too. A way to define the possible output and what values will generate that. This way a user will pick what he desires and we already fill the values for him.

Just to illustrate

User sees checkboxes, radios, select (for list text). If he selects the checkboxes we create a text list using the radio/checkboxes for form widget and with unlimited cardinality. If he selects radios, same as before, but cardinality 1.

Also for the list part I would fill the allowed values with something the user can change so he gets the idea of what he should do

apple|Apple
orange|Orange

This helps new people to not go back and forth through the settings to get what they want in the form.

yched’s picture

Yeah so as @tic2000 points, in the case of a list field, the "default field settings" (list of selectable values = empty array) dont really help present a sample widget that's visually relevant. That would require "sample settings values" in addition to "default settings values".

catch’s picture

- otherwise, we're talking about actual icons (abstract, language/browser/theme-agnostic visual representation of the "idea behind the widget"), and that sounds like asking a lot of design/UX ability from contrib authors - plus, inconsistencies as well

I think there'd have to be a set of core icons that covers all the major patterns plus some non-committal ones, and combine those with a description, and maybe allow custom icons but strongly discourage them.

But yes this is a problem and while I can't find it there's a 10+ year old issue about adding icons to core that got stuck on this same point.

yoroy’s picture

Adding the related issue for what @catch describes in #15.

catch’s picture

@yoroy it looks like the issue reference didn't make it.

yoroy’s picture

I filled out that field too, hmmm. But thanks @jonathanjfshaw :)

yoroy’s picture

Sutharsan’s picture

I had a look at a number of on-line form builders. Although most of them are tailored for contact, response and questionnaire forms, there is enough common ground with Drupal's entity forms UI.

All start with the selection of the type of field, where types are determined by how the field appears to the user. The types mostly follow the HTML input types, sometimes additional types that combine multiple input fields (grid, name, address). Most form builders use icons to identify the field types (except: 6).

Most form builders have a live preview of the selected field type (except: 8).

All form builders have field selection and field configuration on one page with live (Ajax) updates of the preview.

Form builders I used:

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

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now 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.

yoroy’s picture