Meta issue to list small, subtle changes we want to do on Field UI for Drupal 8. The pie in the sky - I know a lot of people really really want the form builder approach - see #1515688: Redesign the Field UI and #1472348: Fields UI improvements using form builder pattern - is not our goal here. Not all ideas have issue created yet, but will be as soon as possible.

Committed to 8.x

I (swentel) started on that FB approach and I still have the code. However, I 100% completely support making changes on the current Field UI as getting my form builder approach ready before 1 dec is just impossible. Once we hit feature freeze, we simply need to take this up as a big community task in contrib and make sure we can hit it for D9 - although even at this point I'm still not convinced that I could live with that approach on entity level, both for forms and display.

Original summary

As maintainer of field_group and co-maintainer of display suite, I know very hard stuff needs to be done when you want to change the field UI. Lots of form altering needs to be done and worse, lots of duplicate code and behavior.
All of this is just a proposition.

What can we do

  • Make the row handles generic and/or more extendible
  • Change the behavior for the field instance and display settings to a popup/modal/overlay
  • Add a system to nest fields in 'groups' which field_group can implement
  • Create a region system by default in field_ui. This will make it possible for Display Suite to pick in rather than override almost everything. By default the hidden section would be a UI-region and the visible should start as the visible or "content" region (by convention or not)
  • Make an early start for a UI switch to DS layouts. This will very much need a separate issue if we try it.
  • Take an attempt to try rendering the row in ajax and not the form?

I would like to check in a new branch what can be done and like to do a suggestion. Question: What is the branch I should branch from to start this intent?

Any recommendations and thoughts would be very helpful.

Comments

Stalski’s picture

I had a talk with swentel about this and there is a lot that "could" be done.

What I would like to try first, is to have regions by default. The default would be both field UI screens having a disabled and a content region.

advantages
- having them in core(form and display) will makes sure no contribs needs to introduce them
- consistency at forms and displays
- contribs can easily pick in to use them instead of doing all sorts of odd things
- use $content as default 1col display
- easier to convert the UI to using the layout display manager

We might even pull "disabled" fields out of the normal UI screen into a section beneath the form. Fieldgroups in d7 already work that way since they are exportables. The "disabled" property is different from the deleted state. We might consider this behavior for fields as well.

Thoughts?

yched’s picture

I'm not sure how "disabled" applies to the "Manage fields" screen.

"hidden" on forms is very rarely intended for *all* users, and is more typically addressed through field permissions.

Stalski’s picture

True. Two reasons for this:
- Let's say fields are already exportable (very much like CTools handles it in D7). disabled would mean: I don't want to use it "yet", the field will be defined but not used. Is this even possible in D8?
- There is already a hidden section in D7 as well. For the moment, we use it for add_new_field. When fieldgroup or other modules that provide an exportable field/fieldwrapper in the UI, they can define them by hook/Annotation but have them default to 'disabled'.
- Most important: consistency in the field UI screens. After 2 years of working with it, that's what bothered me the most. Also if we can get that disabled section in a separate container, it wouldn't have to load while the form is ajax-refreshing. A display object could contain only the visible fields, and that should be the only thing that is passed through by ajax requests. I know this will be handled in another issue, but a display object (linked to the entity_type/bundle/view mode) would be just great.

yched’s picture

Let's say fields are already exportable (very much like CTools handles it in D7). disabled would mean: I don't want to use it "yet", the field will be defined but not used. Is this even possible in D8?

Well, that sounds like what 'inactive fields' currently are - but right now you can't decide whether a field is inactive or not, the system decides (fields whose field type module is unknown/disabled).
Also, inactive fields are a real pain to handle, and I'm really not keen on allowing admins to disable fields themselves. What's the use case you're targeting ?
And I'm not sure whether, if such a feature existed, we'd want to make it that easy and proeminent - "disabled" region that you can simply drag your fields onto. That "hidden" region on "Manage fields" would have a *very* different effect than on "Manage display".

consistency in the field UI screens

Well, yes, "Display Fields"has a "Hidden" region and "Manage Fields" doesn't, That's because "Hidden" does not really apply on the "Manage fields" screen...

Stalski’s picture

Hmm, this is going to be a battle :-)

I'll think some more about it, but especially how I can be persuasive. Imo we can only go further and improve the current field UI if we can make some things consistent and make it usable.
My girlfriend for instance just ran away from drupal just because she does not have regions in the node form.

As I said, I 'll have some conversations with swentel and zuuperman (or you) some more and try to explain it better.

Stalski’s picture

After talking to some people like yched, swentel, eclipseGC the best thing to do there seems to sketch something that could be the first step.
So don't expect too much of this. For me, this is just the first step to make it easier for all other things to happen.

I've read lots of propositions, discussions and idea's about this. Then I mean page manager, spark, layout manager, panels api ... . I think what is proposed here, is just a very small improvement of field UI (and only that!) and it meets the requirements for almost every choice that could be made for the next generation fields handling.

I will work on a sketch for the modal as well. This modal would then appear on the cogwheel for editing field instances or display settings and when creating a new instance.

field_ui_region_links.jpg

field_ui_region_links_configure.jpg

In code, the regions would be the same for field overview and display overview. Visually the hidden/disabled/unused region would behave differently on both screens.

Shoot!

swentel’s picture

Looks great overall - maybe the grey background of 'content' looks a bit weird, but I can get used to those things.

One thing already mentioned in IRC is that the cogwheel in the upper left and the operations on the right in every row should probably become the CTools dropdown button once that lands in core, see #1608878: Add CTools dropbutton to core.

- edit - added operations too

sun’s picture

Project: D8 Field API » Drupal core
Version: » 8.x-dev
Component: User interface » field_ui.module
Issue tags: +Usability, +Field system

Sorry friends, but this discussion belongs into the Drupal core queue, so the suggested UI changes gain some more visibility.

Stalski’s picture

No problem, I think it's for the best.

I'll work out a next sketch with the new action dropdown links.

Bojhan’s picture

Swentel pointed me to this, I think it makes a lot of sense for fieldgroup. But makes less sense for the overall adding of things. For fieldgroup what you want to do is add a field just below it, while for overall you generally just want to add a "thing" that being fields/fieldgroups or something else (we honestly should be using local actions for this, but it doesn't scale well yet).

I imagine for fieldgroup we should seek to just go down the normal route, of adding a ctools drop button on the right in the operations column. This isn't in core yet, but I assume it will be. The styling might need some additional tweaking to allow this to happen. Any module that wishes to do this should be able to do so.

I don't think normal fields, should have a dropbutton with the "add" action. The overall add action should either remain inline (ugh :D!), or be moved to the top with a more scalable action pattern.

I don't think this should open in a model/overlay. Let's have a consistent model for adding things, the fact that views opens some of these links in modals is nice - but Views has a whole load of UX hacks (I cannot control that, the UI will go into core unmaintained and probally not reviewed by the UX-team). And I would really love for anywhere we can control to have a consistent expectation pattern, what happens if you click a link in a table.

Stalski’s picture

Hi Bojhan,

Thx for sharing your thoughts on this.

About the consistency, I don't think it is very consistent to *not* open a modal, since we will do that to edit a field('s display). So that's the main reason for that change.
Another one is, that if we still have fields beneath the complete form, it's very unusable with a lot of fields and fieldgroup. You always need to drag stuff out of the viewport, and I work with fields UI on daily basis :(
So I am very much in favor of consistency, so that's why all the configurations needed to add a field/fieldgroup/fieldcollection/whatever are fit a the modal. The edit screen will do it as well, AFAICT.

About being good for fieldgroup, I did not think about that yet. The point is that there need to be actions for a region, and so that modules can hook into it. Field collection can pick on it too, as you can see in the attached images. We can now offer styling and behavior for the region wrapper as well this way.

you generally just want to add a "thing"

Well, that's the point, you have to click at least 2 steps to actually create a field or something else. Also modules like display suite can easily pick in the Display overview to be able to create a "Add new codefield" field, immediately in the correct region.
Besides, the approaches I read that deal with Field UI in general are mostly with panel region links. Am I wrong about this?

be moved to the top with a more scalable action pattern.

Can you elaborate on how you envision this?

Attached are the changes suggested by swentel.

field_ui_region_links_2.jpg

field_ui_region_links_2_open.jpg

Stalski’s picture

Title: Make it easier for other modules to add or change the fields overview (FIELD UI) » Make it easier for other modules to add or change the fields overview

Changed the title as it's now under Field.ui component.

Stalski’s picture

After some IRC talk with people, some things might be changed:

1) when there is only one region, as default in core, then "content" should not be there as region label
2) edit/delete on fields (or other rows) can be in a dropbutton as well, maybe even the field_type and widget settings.
3) if you can only add a new field, then this should not be a dropbutton. (consider that as soon as you have other fields, the add existing field appears)

Also in regard to

And I would really love for anywhere we can control to have a consistent expectation pattern, what happens if you click a link in a table.

Totally agree on that. How I thought about it, it's like a javascript enabled/disabled thing. If javascript is not enabled or when fatal errors blocks execution, then the callback can still go the page where you have the add something screen. But It might not be the reason to not show the same thing in a modal, still following the same consistent convention.
I am not all that much following all those UX guidelines that make it into D8, so sorry if I say stupid things.

Also it might be best to separate this issue. I could start with the region thing and then handle the cogwheel/dropbutton and modal thing in another issue. Does that sound ok?

swentel’s picture

Sounds like we might want to turn this one into a meta issue linking to different issues so we can make small gradual changes to a more flexible field ui.

  • Use dropbutton - at least the ability to inject easily more 'row types' (field groups, regions)
  • Use modals to configure field and formatter settings - this makes a lot of sense for formatter settings. However creating new fields could still be a 2 step screen though. The same possibly applies to editing field settings because there's more involved than just simple settings.
  • Add region concept to field ui - this will either introduce a new column region which, once there are more, will kill the formatter <hidden> select option on the manage display screens. Important - vanilla core does not know about 'regions', so it can't be visual by default. Second option might more or less follow the 'parent' column which is already in core which was added so field group could do something useful in D7 contrib. The region row then just uses the same parent column but the row will have a property so it can't be indented.
  • Use temp store (over at #1642062: Add TempStore for persistent, limited-term storage of non-cache data) if it gets in so we can kill #857312: Add a "changes not applied until saved" warning when changing formatter settings for D8
  • Get #945524: Field formatter settings hooks in core in. I RTBC'd that one already as there's a need for it

The pie in the sky - I know a lot of people really really want the form builder approach (*) - see #1515688: Redesign the Field UI and #1472348: Fields UI improvements using form builder pattern - is not our goal here.

(*) I started on that and I still have the code. However, I 100% completely support making changes on the current Field UI as getting my form builder approach ready before 1 dec is just impossible. Once we hit feature freeze, we simply need to take this up as a big community task in contrib and make sure we can hit it for D9 - although even at this point I'm still not convinced that I could live with that approach on entity level, both for forms and display.

Stalski’s picture

The first one started at #1786198: Make consistent regions in code for fields UI overview screens.
I'll list them later on.

swentel’s picture

Title: Make it easier for other modules to add or change the fields overview » [META] Gradual changes to Field UI

Changing title

swentel’s picture

Issue summary: View changes

Update summary

swentel’s picture

Issue summary: View changes

Updated tags

nod_’s picture

Issue tags: +JavaScript

This touches tabledrag, tag.

Also I'm seeing talks about modal. This needs to work on mobile or at least not suck more on mobile. Please keep in mind when throwing around ideas :) #1667742: Add abstracted dialog to core (resolves accessibility bug)

nod_’s picture

Issue tags: +mobile

forgot one, sorry.

nod_’s picture

Issue summary: View changes

Add link to dropbutton to core issue

swentel’s picture

This needs to work on mobile

As in, on iphone/android or rather tablets ? I'll be bold, I don't see myself configuring new fields or changing the display on my android - even though it could be theoretically possible ...

- Edit - typo + added link to summary

Stalski’s picture

@nod_: I can easily reassure you that I won't introduce or throw idea's of any kind ;)
I only plan to use things that you guys already introduced, like the modal that goes into core, the dropbutton if it is included into core, ...

Also as swentel said, I can't imagine people to use the fields UI or views UI on their phone. A tablet should be supported, but as I mentioned above: if a modal gets included into core which is integrated for mobile applications, fine.

- Edit - Besides, the non-javascript way should work as well. So there is always something possible with the normal (read default) approach.

andypost’s picture

Issue summary: View changes

Add link of modal

swentel’s picture

Issue summary: View changes

Refactor issue

swentel’s picture

Issue summary: View changes

Added ajax callback issue

swentel’s picture

Issue summary: View changes

Added 'done' section

andypost’s picture

Suppose a very related issue #1787634: [META] Decouple layouts from themes
EDIT: now there's a working layout_manager in issue pointed above

andypost’s picture

Issue summary: View changes

Updated issue summary.

tim.plunkett’s picture

tim.plunkett’s picture

Issue summary: View changes

Updated issue summary.

tim.plunkett’s picture

Issue summary: View changes

Updated issue summary.

swentel’s picture

Issue summary: View changes

Updated issue summary.

swentel’s picture

Issue summary: View changes

Updated issue summary.

swentel’s picture

Issue summary: View changes

Updated issue summary.

swentel’s picture

Issue summary: View changes

Updated issue summary.

yoroy’s picture

yoroy’s picture

#1830822: Split the Views UI listing into two tables for enabled and disabled might be a useful pattern to apply to the 'Manage display' page as well.

yoroy’s picture

Issue summary: View changes

adding #552620

swentel’s picture

Issue summary: View changes

Dropbutton on field ui done

swentel’s picture

Issue summary: View changes

Adding modal api issue

yoroy’s picture

I wonder if we could hide the tabs for Comment fields and Comment display if comments are off for the given content type. It would clean up the UI for the majority of use cases.

swentel’s picture

Hmm, that makes sense in a way, the code for that is not that ridiculously hard.

yched’s picture

@yoroy: I don't think there can be a case where "comments are off for a content type".
The "Default comment setting for *new* content of this type" can be set to 'closed', but there might still be existing nodes with existing comments displayed, and the comments can still be opened node by node.

yoroy’s picture

Bah :-(
#2021353: Hide comment fields and comment display tabs if comments are off for the content type

90% of content types won't have comments enabled, nor won't have any added individually. I understand what you're saying yched. Pity that the less likely scenarios have to clutter the default state. Anyway! :-)

swentel’s picture

Ugh right, makes sense.

andypost’s picture

andypost’s picture

Issue summary: View changes

Updated issue summary. Also content types ui doesn't belong to field ui :)

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.

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.

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

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

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