Move "Field list" and "Views plugin" pages from Reports to Structure

Yes, let's move them!

The only downside is that it's even more menu items (well 1) in the already overloaded Structure section. But I think it' a worthwhile tradeoff because it's actually the answer to accidentally clicking on comment types when you want content types.

The paths are still /admin/reports/fields and /admin/reports/views-plugins. Maybe/probably they should change to reflect the new parents in the IA?

I think the "Views plugins" link should probably go under "Views" (or maybe be a tab on "Views") rather than being a first-level item under "Structure". Not sure if we want that one in the same scope here or not since I think it's of a different level of relevance (related only to Views) vs. the field list (related to every fieldable entity type).

Added some before screenshots to the summary. Here's the current "after":

Editing to make the screenshots not giant; forgot to fix the high-res thing.

I work on this issue in Vienna2017

Okay I have tested the patch against 8.5.x and it is working fine

Screenshots in #8 are still valid (checked)
Paths and titles look ok.

I agree that it would be useful to bring these listings closer to the interfaces where they are most useful. I don't think adding them to the Structure page is necessarily the best way to connect these dots. The structure page is already too much of an undifferentiated mix of primary, heavy use items (content types, views, menus) and less often used items like comment types, contact forms. (And what are Views plugins anyway?)

I don't think these items should be presented on the level where you can still choose between working on (for example) your content types, navigation or views. These lists would ideally be linked only on screens where they are relevant. Similar to what #2721727: Allow user to add display modes from respective field UI's. wants to do.

Can we look into other ways to connect these related screens? I'm thinking about #1440678: New users have difficulty finding where to adjust the content model for example. Another route would be to get busy with #2518960: Emphasize the most important items on the 'structure' page.

In it's current state of alpha sorting whatever links are on this page, adding more items to this list, where those items only *support* *parts* of the functionality on offer there is not the better trade-off.

Please only tag string changes after the issue is actually committed. Thanks!

I applied patch #14 manually for version 8.4.x and observed that Views plugins is not showing in structure after applying the patch !

Before applying patch

After applying patch

Adjusted the patch, 'Views plugins' link has come back

Seems like a screenshot is already uploaded.

#19 was not addressed

Attached patch against drupal 10.1.x

try to fix CCF #37

I am working on fixing #38.

Tried to fix the #38 error. Please review.

Folks, please don't work on this until we get buy in from the UX/product team

In #19 they expressed that they didn't support it.

I would recommend taking it to the usability team via the #ux channel

FWIW I don't agree with this change either

Based on #19 this looks like it should be won't fix.

Usability review

We discussed this issue at #3467007: Drupal Usability Meeting 2024-08-16. That issue will have a link to a recording of the meeting. For the record, the attendees at today's usability meeting were @benjifisher, @rkoller, and @simohell.

On one hand, we see the point of moving the Field list and Views plugin pages from Reports into Structure. We've considered the two personas relevant in this case, site builders and site administrators. For someone monitoring a site, looking at log messages, 404 errors, keeping a constant eye on the site's status report, the Field list and Views plugin page are not that much of interest nor help. Site builders on the other hand who are building views, creating content types, and other entity types, for them those two pages are way more important and helpful.

But on the other hand, the top level menu items in the Drupal Admin UI don't group tasks for the needs of different personas, instead they are grouped thematically. So under Structure one is able to actively alter the information architecture of the site, while the sole main purpose of the pages under Reports is informational. That clear separation of concern would get diluted by moving the two pages. The other aspect to note, the sub menu items under Structure are sorted alphabetically. That way, the menu item Views plugins would be right after the menu item Views. The page providing the information about views would be in close proximity. That is not the case for the Field list menu item. During the meeting we've only considered Content types as the sole place containing fields, and noted that the menu item Field list is not right next to the menu item Content types, Display mode is in-between. And that is only for the case of English, for other languages these gaps might be even more significant. It has to be added, I've noticed and remembered while writing up the comment, that the Field list page not only provides information about fields for Content types, but also for Content blocks, Comments, Media, Views, and Users. The latter could not even be found under the top-level menu item Structure but Configuration.

So yes, we think it is a good idea to give site builders another way to access those two pages, but the proposed resolution is probably not the right way to solve this problem. @yoroy already suggested three alternative approaches how to improve the situation in #19 with #2721727: Allow user to add display modes from respective field UI's., #1440678: New users have difficulty finding where to adjust the content model, and #2518960: Emphasize the most important items on the 'structure' page. We thought we might even need a sort of more comprehensive solution for interlinking admin pages. We protentially need a standard structure, some sort of API, for specifying where to put those links. #3325034: Providing additional methods of navigating the admin interface might cover the technical foundation for that API, while the underlying navflow might be informed by the work in the context of the Drupalisms working group.

To summarize things and to answer the question @quiteone raised on the #ux channel on the Drupal Slack. We agree with @yoroy and @quietone and would also suggest closing this issue in favor of one of the aforementioned other issues.

@rkoller and the usability team, Thank you!

I have updated the issue summary and status based on #45. This is now won't fix and work can continue in the issues listed in the proposed resolution.