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

Issue tags:+Usability
StatusFileSize
new169.26 KB
new345.11 KB
new234.01 KB
new202.43 KB

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

StatusFileSize
new96.73 KB
new162.41 KB
new134.87 KB
new109.04 KB

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