- 🇳🇿New Zealand quietone
Thanks to rkoller for telling me about the meta issue.
- Assigned to arunkumark
- Issue was unassigned.
- Status changed to Needs review
3 months ago 1:31pm 12 August 2024 - 🇮🇳India arunkumark Coimbatore
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.
- 🇮🇳India sagarmohite0031
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.
- Assigned to sagarmohite0031
- Status changed to RTBC
3 months ago 3:01pm 14 August 2024 - Status changed to Needs review
3 months ago 3:24pm 14 August 2024 - 🇩🇪Germany rkoller Nürnberg, Germany
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.
- Status changed to Needs work
2 months ago 2:56pm 21 August 2024 - 🇩🇪Germany rkoller Nürnberg, Germany
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
andSetting 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 dedicatedSettings
button, same as a dedicatedInstall
orUninstall
button, only all theSet 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
, theAppearance
page and theExtend
page in general withProject Browser
andRecipes
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 BrowserBrowse
page (admin/modules/browse
) and theExtend
page (admin/modules
in general.On
admin/modules/browse
it is currently possible to display the source types forDrupal.org (JSON:API)
which is using the endpoint for Modules on drupal.org,Recipes
, andDrupal core
. None of the modules listed in theDrupal.org (JSON:API)
source type is contained in the file system yet, only those showing theAdd and install
orInstall
button. In contrast,Recipes
currently only contains recipes shipping with Drupal Core which are already contained in the file system BUT sooner or later theRecipes
source type will also be able to list and query recipes on d.o not contained in the file system. TheDrupal core
source type simply mirrors a subset of the modules found onadmin/modules
, but all of them are already contained in the file system. That lead into talking about the current state ofadmin/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 onadmin/modules
in the form of theLayout 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 improvingadmin/modules
. In general theExtend
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
andUninstall
tab and name itModules
, and introduce dedicated tabs forRecipes
andThemes
. That means moving theAppearance
page into theExtend
page within theThemes
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 theAppearance
page that often, after the sites themes and theme settings were initially set. It is therefore not really necessary to keepAppearance
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 theConfiguration
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 onadmin/modules/browse
. It might be even worth to consider adding dedicatedAdd 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 entireExtend
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 theExtend
page in general. - 🇩🇪Germany rkoller Nürnberg, Germany
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?