Providing additional methods of navigating the admin interface

Problem/Motivation

While presenting #3318110: [meta] Reorganize Block items in the administration menu to colleagues for feedback, one person noted how they quite often find themselves spending time jumping around to different parts of the admin interface.

For instance, after adding a field on a content type, then configuring it, they have to jump over from Structure to Content to see/test their changes; They then jump back to Structure to make additional changes or add another field, and if they have multiple fields to add/change, they find themselves repeatedly clicking through multiple screens to get from one deep part of the admin UI to another.

I gave this problem some thought and came to the conclusion that, while we currently have a way to navigate the hierarchy of the admin UI, we don't currently have a consistent way to jump between related parts of the admin UI.

There are some cases where related parts of the admin UI are deep-linked between each other. For example, the Block Types collection provides a link to the Custom Block Library, however this link is displayed within a short paragraph of help text at the top of the list, and so it may be easy to miss.

In #2987964: Move custom block types admin link to admin/structure we are proposing to remove this paragraph because, in the interest of consistency, none of the other collection pages under Structure provide such help text, and so it seemed better to be consistent, and instead solve the problem more holistically.

The intention of this issue is to provide a space to discuss this problem in more detail and propose some solutions.

Proposed resolution

I presented the problem at #3323771: Drupal Usability Meeting 2022-12-02.

During the usability meeting I proposed an idea of a "related links" or "quick links" pattern for the admin UI. This could be displayed at the bottom of admin UI screens, so that it is non-intrusive but still noticeable.

The key advantage of such a pattern is that it would provide a consistent approach for deep-linking across relevant parts of the admin UI. Such a component could even link to relevant help topics.

During the meeting we discussed that such links should be clearly visible: unlike the Block Content example, these links should not be displayed in-line with other text and should instead be presented in a list and/or using a button style. This would help them stand out and be easily discoverable.

During the meeting we also discussed other possible solutions:

• Integrating elements of the Admin Toolbar module, to make it easier to quickly jump through the menu tree in the toolbar.
• The admin UI may benefit from a way to quick search for different screens/settings, the Coffee module does this well by providing a MacOS Finder style search overlay, which can be quickly brough up using a keyboard shortcut.
• The Gin admin theme, provides new styles for the toolbar; Most notably a vertical style which displays the toolbar down the left side of the screen. Anecdotal evidence suggests this is popular, based on the fact that this is the default style when using Gin and Gin is currently in use on over 22K Drupal 8/9/10 sites.
• We also noted that the existing Core Toolbar has a vertical tray style, which we agreed was easier to navigate quickly because it allows expanding out the hierarchy without needing to click through different screens. And when the user clicks onto a screen, the hierarchy stays expanded at the level the user has navigated to. We also noted that this is not the default tray view and aside from a small button on the far-right of the toolbar, it may not be obvious to many users that this view of the toolbar tray exists.

This issue does not need to solve this problem, it can be used as a place to discuss the various potential solutions, and could evolve into a meta issue.

It should also be noted that while #2755613: Restructure the admin interface Information Architecture does exist, it's focus is more about reorganising the structure, and regardless of the outcomes we would likely still end up with a hierarchy which would benefit from more than one approach to navigation.

Remaining tasks

• Discuss the possible solutions, potentially opening child issues against Drupal Core for any quick fixes that we can identify.
• Gather examples from other applications (not just Content Management Systems) and other systems which have a large number of settings screens (for example Windows and MacOS), to understand what approaches work well and what we can learn from them.

User interface changes

API changes

Data model changes