Add drop-buttons to the appearance page

Thanks to rkoller for telling me about the meta issue.

I elaborated on the issue summary and created MR to achieve the feature. The changes are related to the User interface. Now the MR ready for review.

I've Tested MR 9181 on Drupal 11
MR showing failed pipeline but MR is applied Successfully.

Testing steps-

Visit the admin theme appearance page.

Please check attachments for reference.

I'd like the usability team opinion on this one.

The issue would need a rebase. on a none case sensitive file system ( i am on a mac) i run into the following error:

$> git checkout -b '1973322-add-drop-buttons-to' --track drupal-1973322/'1973322-add-drop-buttons-to'
error: The following untracked working tree files would be overwritten by checkout:
	core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestMysql/Connection.php
	core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestMysql/Install/Tasks.php
	core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestMysqlDeprecatedVersion/Connection.php
	core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestMysqlDeprecatedVersion/Install/Tasks.php
	core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestPgsql/Connection.php
	core/modules/system/tests/modules/driver_test/src/Driver/Database/DrivertestPgsql/Install/Tasks.php
Please move or remove them before you switch branches.
Aborting

it happens when the issue fork was created or last rebased before this issue went in https://git.drupalcode.org/project/drupal/-/commit/8b368d712d83900765744... on the 13th of august fixing spelling errors. the switch to camel case is the problem where the none case sensite file system in combination with git struggles and leads into this error.

For the rebase needed for usability

We discussed this issue at 📌 Drupal Usability Meeting 2024-08-23 Needs work . The direct link to the recording of the meeting is: https://www.youtube.com/watch?v=1Cc4acYPPiw. For the record, the attendees at the usability meeting were @amazingrando, @avanibhut, @ofershaal, @rkoller, @simohell, and @zetagraph.

Sorry that it took more than a while writing up the comment for the meeting, but getting everything into a coherent and comprehensible order was kind of tough, plus I was quite occupied helping getting the quiz, the Drupalisms Working Group was working on, ready in time for Drupalcon Barcelona.

First we've taken a look at the screenshots in the issue summary, since I was unable to apply the MR on my computer. The one thing that worried us was that all available buttons are thrown into a single drop button. Per default you get to the Settings option but the rest is a heterogenous blend of options/actions. It was also noted that the drop-button is left aligned in contrast to the Drupal Design System where the buttons are right aligned for LTR.

At first we've asked us what problem "combining all the available buttons in a single drop-button" is actually solving? On one hand the card becomes more aesthetically pleasing and more cleaned up, but on the other hand one extra click is required by the user to actually invoke an action. If additional actions are being added to this drop-down as options in the future it might make more sense. But these three items have been on a theme card for a long time and as a user, one of the attendees noted, he likes being able to directly click a button instead of first clicking on a drop down and then making another selection. The heterogenous list also puts a toll on the user in regards of the cognitive load to process the list of available action. If the number of actions is rising in the future that load increases as well. It was also noted that clicking the different options has varying consequences, the default settings is redirecting the user to another page while Uninstall and Setting as default induces immediate change right on the page. A separation of concern, at least to a certain degree, is important and would desirable here.

We then took a look at a related child issue #3249379: Make all form submissions on the Appearance page consistent → which is also part of the meta issue ✨ [Meta] Appearance page is too long and confusing Active - it takes a similar but slightly different more holistic approach. It suggests to make all form submissions on the Appearance page consistent, meaning to remove the “Choose the administration theme" form at the bottom of the page and enable the user to set the administration theme by pressing an action button, same as for the default theme. In regards of these action buttons the issue takes the middle ground between the current state and the state this issue proposes. There is a dedicated Settings button, same as a dedicated Install or Uninstall button, only all the Set as-options are wrapped within a drop-button. Not a heterogenous list but a slight separation of concerns is accomplished that way.

We’ve then branched out. In recent months there was a lot of discussions and movement around Block content, the Appearance page and the Extend page in general with Project Browser and Recipes on the horizon.

During the effort reorganizing the menu items related to block content in the Admin UI 🌱 [meta] Reorganize Block items in the administration menu Active there were discussions and plans to move the block layout page (admin/structure/block) into the Appearance page (admin/appearance). There were two approaches under consideration, adding a layout tab to the Appearance page #3318112-22: [PP1] Move "Block layout" from Structure to Appearance → or moving each block layout page into the respective themes card #3318112-23: [PP1] Move "Block layout" from Structure to Appearance → . The issue got postponed on 🌱 Restructure the admin interface Information Architecture Active which is about rearranging the information architecture of the Admin UI. Then the question was raised by one attendee if themes are on the roadmap for Project Browser. It was noted that at this point Project Browser only supports the source types for Modules and Recipes, but there will be a source type for Themes sooner or later. That brought us talking about all the different concepts on the Project Browser Browse page (admin/modules/browse) and the Extend page (admin/modules in general.

On admin/modules/browse it is currently possible to display the source types for Drupal.org (JSON:API) which is using the endpoint for Modules on drupal.org, Recipes, and Drupal core. None of the modules listed in the Drupal.org (JSON:API) source type is contained in the file system yet, only those showing the Add and install or Install button. In contrast, Recipes currently only contains recipes shipping with Drupal Core which are already contained in the file system BUT sooner or later the Recipes source type will also be able to list and query recipes on d.o not contained in the file system. The Drupal core source type simply mirrors a subset of the modules found on admin/modules, but all of them are already contained in the file system. That lead into talking about the current state of admin/modules and its inherent problems.

At the moment the sole touch point a user has with the concept of a recipe is on admin/modules/browse. But aside that there is no way for a user to see which recipes are available and more importantly which got already applied. A detail for example completely inaccessible to someone less technical who tries to understand which recipes got applied for building their install of Drupal CMS, or someone getting new into an existing project and they try to understand the setup - which modules are installed, which settings got set and which recipes got applied?
Then there is another concept hidden on admin/modules in the form of the Layout Builder Expose All Field Blocks (Deprecated) module, which technically IS a module, but conceptually a feature flag, enabling the user to enable or disable a certain feature.
admin/modules itself is an overwhelming page, in particular in Drupal CMS with complex modules like Webform and ECA installed. In addition to many modules and submodules you have several module groups, some modules even add their own group(s). The list of installed and to be installed modules (admin/modules) and the list of to be uninstalled modules (admin/modules/uninstall) is on separate pages. In addition to that, the list of to be uninstalled modules is sorted alphabetically with no grouping - uninstalling a module therefore turns into a scavenger hunt of two or more uninstall steps to remove dependent modules and content upfront. Then you also have the problem of checked and uncheck checkboxes on both pages which have certain flaws in regards of accessibility and user experience. There is an overarching meta issue 📌 [PP-3] Figure out what to do with the install/uninstall modules page Postponed for improving admin/modules. In general the Extend page, in its current form, has several overlapping concepts, making it challenging to use and interact with. The user is required to know and understand all the underlaying, in part implied, constraints and concepts.

We’ve then talked about one potential approach how to tackle all these overlapping concepts. Suggestion was by “simply” merging the List and Uninstall tab and name it Modules, and introduce dedicated tabs for Recipes and Themes. That means moving the Appearance page into the Extend page within the Themes tab. That last idea was based on a comment by @cellear in one of the Drupalisms Working Group meetings. He pointed out that usually a user doesn’t have to visit the Appearance page that often, after the sites themes and theme settings were initially set. It is therefore not really necessary to keep Appearance as a top-level menu item in such a prominent position. Feature flags on the other hand could either go into another tab or move into a setting page under the Configuration top-level menu item.
That way you would have Modules, Recipes, and Themes that are available in the sites file system, while everything not in the file system yet, would be browse- and searchable on admin/modules/browse. It might be even worth to consider adding dedicated Add module, Add recipe, Add theme-buttons on the respective tab pages, and after clicking the button you only see the specific source type in project browser of the button you just pressed. That way you would reach a clear separation of concerns for all the different concepts across the entire Extend page while reducing the number of top-level menu items by one. A pattern WordPress applies on their plugin page (wp-admin/plugins.php) as well. We also took the time to take a quick look at a current WordPress installation and noted that the plugin page is highly condensed and functional, communicating clearly all the necessary information.

So the overall consensus for the Extend page in general was, it would be reasonable and desirable to bring together folks from the usability group, the Recipes group, the Project Browser group, the Drupal CMS group, and whoever is interested discussing the constraints and requirements that have to be minded, for having a viable solution of the Extend page.

Circling back into the scope for this issue, it has to be noted that close to the end of the meeting we’ve managed it after all to set up an instance with the MR applied and manually test things. Some of the attendees changed their opinion, about having a single drop-button, based on that manual testing. It was acknowledged that some sensible defaults are being used, for example for not installed themes the default is set to Install. But nevertheless we haven’t come to a clear consensus because the other half of the group was still on the fence, since even though the pages look visually more organized by hiding the more unusual options you still have in part the issue with the separation of concern.

So in summary it is hard, or close to impossible, to come up with a clear recommendation. The suggested solution has a certain appeal, but with all the movement and discussion currently happening in Project Browser, Recipes and Drupal CMS as well as 📌 [PP-3] Figure out what to do with the install/uninstall modules page Postponed we would suggest to postpone the issue for now until there is a clear path forward in regards of the Appearance page and the Extend page in general.

I wonder if it would make sense to rescope #3249379: Make all form submissions on the Appearance page consistent → ? As mentioned in #26, this issue and #3249379: Make all form submissions on the Appearance page consistent → are overlapping in regards of a drop-button solution. So would it make sense to make #3249379: Make all form submissions on the Appearance page consistent → only about dropping the admin theme form at the bottom of the page and switch to an action button based approach instead? And remove the drop-button part and leave a note about that notion on this issue, of not dropping all available options into a single drop button but having a combination of a drop-button and one or two action buttons?