Separate the menu settings from the 'add link' button

Hello,

This is my first contribution to Drupal core.
I hope this patch resolves the problem. If not, I'm opened to learn... :-)

Thank you.

   public static function create(ContainerInterface $container) {
     return new static(
-      $container->get('entity.query'),
-      $container->get('plugin.manager.menu.link'),
-      $container->get('menu.link_tree'),
-      $container->get('link_generator')
+      $container->get('entity.query'), $container->get('plugin.manager.menu.link'), $container->get('menu.link_tree'), $container->get('link_generator')
     );
   }
 

I don't think this should go on one line.

Other than that it looks good to me.

In addition to #5

+++ b/core/modules/menu_ui/src/MenuForm.php
@@ -104,13 +101,22 @@ public function form(array $form, FormStateInterface $form_state) {
+      '#collapsible' => TRUE, // Added
+      '#collapsed' => FALSE, // Added

What is the purpose of the "Added" comment?

Besides that, this patch looks ok.

I am wondering, why isnt this on a separate page?

Hello,

#5 dylanf: My IDE has formatted the file. I haven't seen it.

#6 geertvd: I have added this comments to remember the addition of this lines and I have forgotten to remove it.

I can commit a new patch if it's necessaary.

Thank you for the comments.

Yeah, that happened as part of #663946: Merge "List links" page into "Edit menu" page

Its confusing that we basically want to revert the previous change ...

I am not sure if there is really a right solution here, we don't really have a good pattern for forms that are placed on listings.

What about placing it in a fieldset, below the listing? Collapsed by default?

Patch is fine for me as well. But I also have my doubts in the general display of this page. Probably the separation of links is better.
I also do think this might be a broader problem with the styling of action links.

At least in my point of view I am also fine with this solution.

Before

After

I am not sure whether we should continue with this issue given that the "Add link" no longer appears in menu edit page (as per issue summary).

@subhojit777 - Are you checking the same in 8.0.X branch ?

Applied the patch #10
Please check the attached before and after images

Before

After

Tested in multiple browser. Moving issue to RTBC.

I also could not reproduce #16. Looking at /admin/structure/menu/manage/main in HEAD, I have the Add link button there as shown in #17.

The current patch on the issue is not being tested properly because it was submitted before we migrated to the new testing infrastructure, so I think we need to reupload it.

I agree with not reverting #663946: Merge "List links" page into "Edit menu" page which was intended as a usability improvement based on actual user testing, at least not without further consideration. Looks like the latest solution could probably do with a usability review. It does look better to me, but this is a pattern that also would affect other places in the UI as well, such as:
/admin/structure/block/block-content

On the other hand, Taxonomy still has them as separate pages; compare with:
/admin/structure/taxonomy/manage/tags/overview
/admin/structure/taxonomy/manage/tags
...Actually this is because @Bojhan closed the related issue as a wontfix; see #1340500: Merge "list terms" page into "edit vocabulary" page. I reopened that issue, but postponed it on this one.

Finally there is also #2421011: Make shortcut add and edit form titles better.

The current form is not good UX-wise, but AFAIK neither is having unneeded form elements. Also, this has the effect of separating the menu settings from the tablerag that also belongs to the same submit button. I think the real problem is that there are three separate actions on this page--two that use one submit button, and one that use the other--without any clear separation between them. This also might be a weakness with our implementation of the + Add thingy button pattern that is used in many places.

Tagging for usability review so we can see whether the new proposed fieldset is actually moving us in the right direction. If it's not, we should consider whether there are some other designs for this and other forms that would be better. Also, I'm not sure we should make this change without making other similar forms consistent, because that would affect the product experience/integrity... so tagging for product manager review for that. And finally, since this is a UI change, moving to 8.1.x per https://www.drupal.org/core/d8-allowed-changes#minor.

Thanks everyone!

Hey everyone,

Wanted to throw my 2 cents in on this one. Separating into two pages would be fine, but I think the big issue with the 'Add Link' button is that it's just in the wrong spot. As indicated in the original description, the location of the button above the menu options makes it look like it's the same thing, but, I don't think adding the field set helps. Instead, I think a few things need to happen (described and shown in the images below):

1. Change 'Title' to 'Menu Title' - Adding Menu helps to describe what the field is for.
2. Change 'Add Link' to 'Add New Link' - Maybe unnecessary here, but another descriptive term for clarity.
3. Move 'New Link' button - OPTION 1 - Move the button above the list of links while leaving enough space above it to separate it visually from the Menu Title and Summary. I believe having the button in this location, with the other links, ties it in better with the expected action.
4. Move 'New Link' button - OPTION 2 - Alternate location for the button where it's actually within the the Menu Link area.

OPTION 1

OPTION 2

Also, I think it's important to keep in mind that whatever is decided placement-wise should really be continued throughout Drupal 8, for consistency.

#19: "the big issue with the 'Add Link' button is that it's just in the wrong spot": Agreed, +1. Action links do go at the top by Drupal convention, but that pattern seems wrong when it comes to creating child items that are listed as part of the current page.

#19.1 Menu title: +1
#19.2 Add new link: +1. It's debatable like you say, but may help a little.
# 19.3 Add new on top of link table. This relies entirely on the spacing between it and the form above to work. There's a real danger that it will actually increase the core problem of this issue, because when it's put below the title/summary form it looks even more like a submit button for it. This problem gets worse when there are many links already and so the real save button gets pushed below the fold.
#19.4 Add new link in the headers for the link table. That works OK, but I doubt it's buildable in practice. It's a very fragile piece of positioning and spacing.

How about:
1. Rename "Save" to "Save menu"
2. Ideally, it would be great to have "Add new link" as a bottom item in the link table, but I doubt that's easily achievable.
3. Instead, either
a) Have "Add new link" just below the link table, and then a spce, then the "Save menu" button;
or b) have "Add new link" to the right of the "Save menu" button.

Looking at the original #663946: Merge "List links" page into "Edit menu" page I see that having the "Add link" above the link table, not at the top of the patch, was the consensus of that issue. It seems to have got moved to the top of the page either late in that issue or elsewhere. As I said in my previous comment, I think having "Add link" underneath title/summary will fool people into clicking it as if it were a submit button for those.

A possible solution is to make use of the "machine name design pattern". That is, have title and description not be a form by default, but have an edit link (or 2) that turns them into a form and gives a new inline save button just for them.

If we did this, then it would matter less whether the "Add link" was at the top of the page or above the links table.

I see what you mean re. #19.3 (with the amount of space above being crucial) and #19.4 (fragile area to work with), if we're not solving the problem than it's not a good solution.

I like the idea of moving the "Add new link" button below the table (#20.3), but a potential problem I can see here is when the table becomes long, the button could be missed or just annoying to use (i.e. needing to scroll down every time). Here's a mockup anyway just to see.

Also, here's a mockup for using the 'machine name design pattern'. This is another good option IMO, but it's outside of that normal use-case so I would be hesitant to go this route... at least without maintainer input.

Working on this issue as part of Global Sprint Weekend in Austin, TX.

Uploading the patch in https://www.drupal.org/node/2520232#comment-10084118 again so the new test bot kicks in.

Looking around at the different design patterns in the UI, I see how ubiquitous it is to have the add button above the list it adds to. One can debate how good this is when there are filters between the Add and the list (at e.g. admin/people), but nonetheless it's a product-wide pattern that it can't be right to change on this one page.

However, I see no other cases where a) there is an unrelated form that sits between the add button and the list it adds to and b) the list needs to be a functioning form (reorderable, checkboxes, etc.). And for a good reason, that's just asking for confusion.

There are 3 ways to solve it:

1) Move the Menu title and description form down the bottom, between the list and the save button.
2) Use some version of the Machine name design pattern - perhaps combined with the fieldgroup used in this patch, so that a single "Edit" link" turned a whole group into a subform with its own "update" button. This should probably be combined with moving the Add button to be immediately above the list rather than at the top of the page, even though this is a slight change from the usual design pattern.
3) Revert the parent issue and find an alternative way to solve the problems it set out to solve. That original problem was that "editing a menu" in a users mind meant changing the links equally or more than it meant changing title of the menu. This could be somewhat addressed just by naming the items better. Rather than the original "List links" and "Edit menu" we could have "Manage links" and "Edit menu title", with "Manage links" the default.

Overall, I think 2) is the best option. This would effectively be a new design pattern that could be used in a number of places where there is a need to manage an item that is mainly a list, but has a few additional properties which it would be elegant to manage from the same page.

1) is functional if inelegant, and easy to achieve.

Sometimes the simplest of changes might make the most sense. Rather than add a machine name design pattern, why not just collapse the fieldset since the menu name is 9 times out of 10 a "set and forget" thing? The original patch is using the Drupal 7 form attribute style which is not correct. This makes me wonder how it ever passed the unit tests. I have included a new patch proposal which replaces the Drupal 7 form attributes with the new Drupal 8 style element attributes. See this thread for more details: https://www.drupal.org/node/1852020. By collapsing the fieldset, this should make the form a bit less confusing even if the Add menu link button stays on top of the form. I have also included screen shots of the proposed solution. See below:

Very nice @Uberhacker.

@Bojhan suggested something like this back in #7.: "What about placing it in a fieldset, below the listing? Collapsed by default?"

I think the collapsed by default works well, and it's good to be simple.

If we're going that route I'd like to propose two changes though:
1) Why not move to the bottom, between the list and the save button? This is the drupal pattern we see at places like admin/structure/types/manage/article/display. It's prettier and keeps the Add button nicely tight to it's list without anything unrelated between, making it easier to understand how it all fits together.
2) How about "Menu title and description" instead of "Menu settings" (or just "Menu title")? I wouldn't necessarily expect to find the title in a place called settings, but I would expect other interesting things which actually aren't there.

@LewisNyman back in #9 said "Below the listing? I don't think anyone will find it on most production sites." However, if this is something that rarely needs to be used, this page is the only natural place to look for it, and we label it clearly as "Menu title..." then down the bottom seems fine. Anyone who ever presses the save button will learn of its existence.

@jonathanjfshaw:
Thank you for the feedback. The problem with moving the button to the bottom of the form is that on menus with a lot of items, you would need to scroll down to the bottom of the list each time you needed to add a new menu link. The 'Add menu link' button is actually not part of the main menu link form but a separate block on the page. However, I do like the idea of changing the wording from 'Menu settings' to something else that is more pragmatically correct.

Sorry @Uberhacker, I wasn't clear.

Yes, the Add button must be at the top. I understand this now.
But the collapsible fieldset for menu title and description could be at the bottom, between the list and the save button. That's what I was suggesting in response to your work.

@jonathanjfshaw:
No worries. After reading it again, I probably should have known that was what you meant. I have taken your suggestions and created a new patch proposal.

Very nice @Uberhacker.
I have updated the IS to summarise discussion to date and reflect current proposal.

The "Next steps" section is a bit uncertain though. Could someone who knows suggest what that should be?

Thanks for working on this @uberhacker and @jonathanjfshaw. Very good to see this considerate design discussion :-)

I like the solution you've arrived at and it's indeed in line with what @Bojhan suggested in #7.

As for next steps:

1. A visual review, ideally with screenshots. Would be good to show that this does not touch the flow for creating a whole new menu (where the form that's collapsed here is the primary form). I was going to but https://simplytest.me/ is failing at the moment.
2. Code review. I don't code but I assume this mostly just moves some code around? Find somebody to review the patch :)
3. Once there's been a code review and any necessary changes made we assign the issue to @webchick as she's the product manager.

Actually, lets do that right now and see if she can get us some initial feedback :-)

Thanks again!

Very helpful @yoroy.

The patch applies fine on simplytest.me if you specify 8.0.x; it's 8.1.x that simplytest.me won't do at all.

Ah, good to know, thanks!

@yoroy:
Thank you for the quick reply. The new unit tests passed but after seeing how it missed the D7 element attributes on the earlier patch, I'm wondering about the accuracy of the process. I have included a code review based on PHP Code Sniffer and the latest Coder module. See attached. Someone with more Drupal core experience should determine how many of these issues should be fixed. @webchick maybe?
Thanks

A common practice is to create a followup issue for coding standards etc. issues that don't relate directly to the bugfix/feature that is intended.

@jonathanjfshaw:
I forgot to mention, thank you for the nice screen shots and summary clarifying the patch proposal. I did isolate the code review to the menu_ui.module only but I wasn't sure if any of the code changes might have introduced new warnings/errors in other places within the module, so I included everything for a broader overview of what might possibly be affected. @yoroy, should we reassign this issue back to @webchick? I don't have permission to assign reviewers.
Thanks

Created a new issue regarding the Coder review. Refer to #2666286: Clean up menu_ui to conform to Drupal coding standards.

We've got a problem. As @yoroy wondered in #33.1 the patch causes the title to appear in a collapsed fieldset when creating a new menu at admin/structure/menu/add.

It needs to be collapsed by default at admin/structure/menu/manage/menumachinename,
but NOT collapsed by default at admin/structure/menu/add.

Better in fact would be for it not to be in a fieldset at all at menu/add. The fieldset just adds visual clutter on that page.

@jonathanjfshaw is right:

Menu add:

But from testing the latest patch it seems that the page for admin/structure/menu/manage/ doesn't exist at all:

Choosing "edit menu" gets me the "list links" page instead. Which should also show tabs for navigating to the seperate "edit menu" page":

---

It needs to be collapsed by default at admin/structure/menu/manage/menumachinename,
but NOT collapsed by default at admin/structure/menu/add.

Better in fact would be for it not to be in a fieldset at all at menu/add. The fieldset just adds visual clutter on that page.

Agree with both!

Choosing "edit menu" gets me the "list links" page instead. Which should also show tabs for navigating to the seperate "edit menu" page":

Not any more it shouldn't.
#663946: Merge "List links" page into "Edit menu" page merged "Edit menu" and "List links", which is the whole reason why the present issue arose.

Ohh, sorry, of course. Duh! :)

I checked the administration menu which has many items and missed the fieldset at the bottom.

But then what trips me up is the two options here:

Don't we need to link to an anchor on the page so that in case of many menu links we jump to the bottom of the page to make the fieldset for Menu title visible?

"Edit menu" is the heir to both D7's "Edit menu" and "Manage menu links", integrating the two into one.

The thinking of #663946: Merge "List links" page into "Edit menu" page is that in the user's mind, the "Menu" is a set of links. Therefore they expect the action of "Edit menu" to be about managing the links on that menu.

Changing the menu's title is also a natural part of "Edit menu", but it's something that users rarely need to do.

The point of that issue is therefore to change the UI to reflect a user's natural mental models of menus, rather than the Drupal model in which the menu is an entity with only a title and a description field, and to "Edit menu" is to edit the entity and just those 2 fields.

Therefore the idea is to offer one action "Edit menu" which takes you to a page where the most obvious thing is the menu links and managing them, but you can also (now secondarily) change the menu title.

This is a (subtle) change from the meaning of "Edit entity" elsewhere in Drupal, but it's one that has a solid usability rationale. Menu links may be separate entities to menus in Drupal's data model, but not in the natural mental model of users.

There is a legitimate line of concern that says: it is no longer obvious how to change the Menu's title, this has been buried too much.
The justification of the proposed solution in response to this would go:
1) Editing the title is a rarely used action, so it's fine for it to be a bit buried
2) It's part of "Editing a menu" in a user's mental model, so they would look on the right page for it
3) The alternatives have worse problems:
a) if you give it a separate page, you fight against the user's natural mental model
b) if you put it at the top of the page you hit the issues from the IS of this issue, the UI of the Add link action on this page gets messed up

Sorry guys, been really busy these last few weeks. Really appreciate the good feedback. I've attached a new patch that makes the fieldset visible only on the manage menu page. I've rolled this against the latest 8.0.x-dev branch. Let me know if this is an acceptable solution.

Doesn't this need to be against 8.1? Its a UI change.

The latest patch applies fine against 8.1 and passes tests on it, so I think @uberhacker probably just slipped when he said 8.0.

I have unpostponed the related issues so that this pattern can start to be applied elsewhere.

Could somebody call this to the attention of @xjm or @webchick so we can get code review and product sign off on this?

I like the Title -> Menu title change, but it feels like we're doing the whole "bottom collapsed fieldset" just because we can't position the "Add link" button above the table otherwise?

I would personally expect this layout:
- Menu title
- Administrative summary

- Add link
- Table

- Save

@bojanz I know what you mean about how that is the arrangement one would expect. However, I don't believe that works.

1. It doesn't stop necessarily the IS problem. People may still think that those fields refer to the menu link they want to add. OK we've labelled it more clearly, but the layout is still suggestive.
2. It puts the Add link button right where you'd expect a save button to be for those fields. OK it's labelled differently, but it's easy to hit the button automatically after updating the fields. Especially if the real save button has been pushed below the fold so that button is the only one visible on screen.

It does seem strange to have the title below the links, but moving the fields below the links clarifies the UI quite effectively.

The add link button looks the same as the Save button, hence the confusion. If it wasn't blue, there'd be less confusion.
I'd also expect add link / edit link to work inline on the form (or in a modal), the fact that those buttons send me elsewhere is a part of the problem.

So our current approach feels like a band-aid, which means that it might help in this specific case, but won't really set a pattern to follow elsewhere.

I agree the add buttons are unsatisfactory in many ways and could do with a fundamental rehaul, and that the solution here only intends to be a bandaid.

However, is a fundamental rehaul of add buttons realistically going to happen soon enough to make this issue not worth committing?

I suggest that this issue can still be seen to set a pattern in a limited bandaid sense, i.e. given that
a) given that add buttons work the way they currently do in Drupal; and
b) we strive to be consistent in our UIs
c) we have 3 cases (menus, shortcuts and vocabularies) that have the same issues, in that they only have a title, description, and a set of children
d) a lot of usability discussion has taken place in the menus case on this issue and its precursor #663946: Merge "List links" page into "Edit menu" page.

then there's a strong case for shortcuts and vocabularies adopting to the pattern that menus have set in that issue and this one.

@bojanz:
I agree that it makes sense to put the 'Menu title' fieldset where it can easily be seen but as mentioned in an earlier post #29, the 'Menu title' fieldset is part of the form included with the menu links. The 'Add menu link' button is actually a block separate from the form, requiring some crazy css wizardry to make it appear to be part of the form if we did what you suggest. I suppose we could integrate the button as a form element instead of a separate block but it would not be consistent with other admin forms and would require sweeping changes.

The pages for "Edit menu" and "List menu items" need to be separated in two separate pages again, even if it means reverting a previous issue. All across core we have a separation of concerns between Configuration (the metadata) and Content (entities).
The list of items are either a tab on the same page, or a separate page (such as Content or Comments), and they have a very consistent "Add foo" button at the top. In some cases, additional filters are added on top of the list.

The separation of concerns provides a clear indication where a user is, and it allows to set permissions so that users can access one or the other.
Typically at least some users of an existing site need to be able to add/edit content (including adding, disabling or enabling menu items), while they might not have permissions to edit the entity bundle (such an a specific menu).
Where users are not supposed to be edit a menu, we need to be able to restrict access to it (instead of hiding it a collapsible field set or so).
This is a usability issue because users have more access to functionality then they need, and it can mess up existing sites.

Where there is a Save button, it should be close to what it's saving, but combining configuration and list of menu items has moved the save button very far. This is a usability issue for site builders. (See the default Admistration menu where the Save button is about six screens down from the configuration, to the point that it's unclear what is saved there.)

Contrary to the assumption in this issue, the configuration for menus (and for vocabularies) is not just a title and a description. Other modules can add additional configuration, such as language settings.

If I get it correctly, the whole issue of merging the List and Edit page for menus because during usability testing users did not understand the difference between "Menu" and "Menu link", not assuming that "Links" would bring them to the individual items.
Menu items are technically links, but "Menu item" would have been another way of naming them. This would have given us "Edit menu", "List menu items" and "Add menu items".
Instead the wording "Link" was kept but the pages merge, creating additional usability issues and a non-standard solution that is now leading to more usability problems.
Exporting this non-standard solution to other places (such as vocabularies) will only lead to more problems. For example: where will you place the Save button when the list of taxonomy terms goes beyond one page?

So, the simple and consistent solution would be to separate Configuration and List again into two pages, and to use "List menu items" and "Add menu item" in addition to "Edit menu".

@ifrik brought this issue to my attention at Dev Days Milan.

So the current patch actually includes two changes:

1. Changing the UI labels to be more specific
2. Moving the menu metadata to a separate fieldset

I think the first item (the label improvements) are worthwhile on their own regardless. However, there is a concern mentioned several times above that I do not think has been addressed: For a menu with more than a handful of menu items, no one will ever find the collapsed fieldset for the menu title at the bottom of the page.

Here are the two other designs presented on this issue that I think address the problem of the collapsed fieldset not being discoverable:

A third option would be to put the collapsed fieldset at the top of the page, rather than at the bottom of it. That way, it's visually separate, but still easy to find.

I agree with @bojanz that this issue feels like a bandaid that might not actually be fixing the underlying usability problem. Finally, I am hesitant to commit this change without some light usability testing to validate whether it actually makes things better or worse. It's not something that simply makes things better; rather, it improves one usability problem at the cost of regressing another (the fact that users expected the concept of "Editing" a menu to include editing the items in it, not just its title) and adding a third one that does not exist in either D7 or D8 currently (the fieldset with the title in it being too hard to discover).

I also see @ifrik's point about the problem with having separate actions as described in #55. However, I also would not want to blindly revert the change to put them on one page without some usability testing to validate which one is better. Again, we would be solving one problem (the button being too close to a different task and there being too many actions in one place) at the cost of reintroducing another (the fact that any sane person would expect editing a menu to allow you to, you know, edit the menu itself and not just its title).

Thinking more about it, what might help site builders understand which field is for would be for the page to actually be modifying the items in context. Editing the menu should actually be editing something that looks like a menu.

Another possibility would be to try using a sidebar accordion for menu metadata, like the pattern we use for nodes and that we are experimenting with in #2684509: [meta] Implement a preview-first Views UI with current functionality. In both cases, we would give the user a preview of the actual thing, which makes it easier to understand which parts of it they are changing.

Finally, I wonder if instead of trying to fix the menu, taxonomy, and shortcut patterns all separately, we could instead look into adding an experimental module that alters the UIs for all three to a new pattern. That way, we can test out a new, consistent pattern without risking regressions for existing site users' workflows, and actually validate whether it makes things better or worse.

Thanks everyone for exploring this tricky UI problem and trying out different solutions!

instead of trying to fix the menu, taxonomy, and shortcut patterns all separately

I propose that at the least we postpone this issue, with its long tangled history, and open a new issue to develop a new unified design pattern. We should begin by having an IS that lays out
a) the various contexts we intend to apply our new pattern to
b) other similar Drupal patterns that we want to be in harmony with, but are not modifying in this issue
c) what the edge cases are that it's easy to overlook (like when a taxonomy listing runs on to 2 pages, or language settings are added, both as @ifrik pointed out)
d) what the various usability problems are that we are trying to navigate between

I like the way you're thinking big @xjm - it seems like trying to find a easy quick fix for these problems is failing, they're too tricky for that to work.

The question that raises for me is whether our new issue should have a broader scope than menu, taxonomy and shortcut. Is there anything else that is similar enough that a bigger change of pattern should include it as well?

Thanks xjm,

I like the idea of looking at the bigger picture and how to improve the usability of several modules as one issue that needs solving and not as a patchwork of bits here and there.
Starting a new issue and describing the entity type for which we want to improve this instead of listing those core modules might also help to keep thinking about the bigger picture.
So I'm all in favour for an experimental issue that can be used and tested next to the current modules.

About the wording:

• Let's use Menu, Menu title and Menu item. If "links" was the problem then it's time to replace that.
• Instead of Add link or Add menu link: Add menu item, but not new because that is only used for installing new projects.
• Instead of Administrative summary: Please use "Description" as it is used across core modules. Otherwise you need to explain why this is a different field.

I’m also really liking xjm’s idea in #56 of creating an experimental core module as a way of adding further consistency to where we configure things like taxonomy vocabularies, menus etc and where the content they contain is managed.

I’ve been thinking that configuration should continue to be under admin/structure but the editing of terms, menu items, comments, content should not take place there - it makes no sense. It should be in admin/content…

Thanks Rachel,
I see your logic of consistency that way round.

XJM, Rachel and who else has ideas about that: Could we get together on Friday or so during the DevDays and discuss approaches to this directly for a bit?

I really like the conceptual idea to separate content persona operations and move them to /admin/content and keep site builder operations in /admin/structure

Is that really the right persona separation? Yes it's the technical reality of content vs config, but perhaps on many/most projects the content of many/most menus and vocabularies is more or a sitebuilder matter than a content editor one?

Maybe it's the right thing to do, but the persona-based argument seems weak?

In the meantime, we solved the identical problem in commerce.
People need to add a product attribute (config entity, same as menu), and expect to edit the attribute values (content entities, menu links).

We built a drag&drop table that embeds the inline entity form for each content entity.
This inline entity form is just

$form_display = EntityFormDisplay::collectRenderDisplay($entity, $form_mode);
$form_display->buildForm($entity, $entity_form, $form_state);

and the matching validation/submission code.

Reference code: https://github.com/drupalcommerce/commerce/blob/8.x-2.x/modules/product/...

Tested the patch (#45) against 8.2.x-dev. Attached screenshots before and after applying the patch.

Separating the Add menu link button from Menu title and summary textfields looks much cleaner and intuitive.

Before applying patch

After applying the patch

This looks fine for a menu with only a few menu items and no other configuration besides the name and the description - but could you provide a screenshot for the admin menu and translations enabled?

I have test the patch manually, And it is working fine as per acceptance criteria.

But i guess we have to reduce the space from "Add menu link" and table. Please check screenshots for reference.

Thanks everyone for continuing this discussion. I look forward to a better admin UI!

I've suggested that #1340500: Merge "list terms" page into "edit vocabulary" page, #2421011: Make shortcut add and edit form titles better, and other forms that have multiple actions on a page (e.g. some of the original scope of #2752915: Rename "Add page" to "Add search page") should have work done to create and validate an overall design before we proceed with individual issues. See #56 and on, with the feedback from @Bojhan, @rachel_norfolk, @ifrik, and others.

Rather than continuing to have this and other issue threads weave between the specific pages affected and the overall problem, which results in confusing issue status, let's postpone these issues on an overall design issue. Postponing on that issue being available. Could someone file that issue for us, incorporating the designs and feedback from the issues mentioned above as well as any others that might be trying to address these admin interfaces?

Thanks!

Also, this issue does not actively need product manager review at this point; the requested overall design issue will, though.