[Meta] Appearance page is too long and confusing

Adding the needs usability review tag to make sure this issue gets picked up.

I like this, it makes the page easier to review, there is unexpected whitespace in the Uninstalled themes group though.

Re: "and many "Test themes" doesn't have screenshots" -- make sure you don't have $settings['extension_discovery_scan_tests'] = TRUE; in settings*.php for your site. ;)

Patch no longer applies, tagging for a re-roll.

Also, we shouldn't directly put <details> into Twig templates like this, or we miss out on some ARIA-related polyfills we get when using a '#type' => 'details' render array. See for example #3119279: views-view-table.html.twig template directly uses details without render array and polyfills. So instead of putting all that directly into the twig, we should have a preprocess that uses render arrays to setup $variables['installed_themes'] and $variables['uninstalled_themes'] and then the twig template should render those directly as {{ installed_themes }} (more or less).

This issue seems to have been created at least partially because of test themes showing up, which is not happening anymore.

I'm not sure the collapsible fieldsets would be an improvement. Especially for the task of adding and installing a new theme this would *hide* the very thing you would come to this page for to do.

The different layouts in how the installed/uninstalled themes are shown do create a visual hierarchy, but not necessarily in the most appealing way. That could certainly be improved but that would be another issue.

Maybe this particular issue can be closed because it's outdated?

We discussed this issue at the #3161932: Drupal Usability Meeting 2020-08-04.

The advice in #17 solves the problem of having all the test themes show up. On a clean installation of Drupal 9.1, I see just two installed themes (Bartik and Seven) and two uninstalled themes (Claro and Stark).

Given that, it seems we should either refocus this issue (with an issue summary update) or close it as Outdated.

One other point came up at the meeting. It is odd that the installed themes are listed vertically (with the details to the side of the screenshot) and the uninstalled themes are listed horizontally (with the details below the screenshot). I have not looked to see whether there is an issue to make this more consistent. The current layout was created in #1861702: Add a responsive grid to the Appearance page, and one should review the comments there before deciding that it should be changed. (I have not read those comments yet.)

I'm working with @rkoller at DrupalCon Europe 2021 who is interested in coming back to this issue from a UX perspective.

I removed the Needs re-roll tag and set the status to Needs work as the approach and proposed resolution needs to be updated after the usability review by @yoroy and @benjifisher.

At first, I agree with @yoroy in #18 that making the Uninstalled themes fieldset collapsed might not be an improvement for the most common task of installing a theme - it would always require one extra click to expand the fieldset each time the user wants to install a theme.

In regards to the point, @benji brought up in #19 about the horizontal cards for installed themes and vertical cards for uninstalled themes - I've taken a look at the linked issue, but I was unable to find any real reasoning behind it. The four-column view for uninstalled themes might have been chosen to provide a visual distinction to the installed themes section. In terms of the base area, the horizontal cards are a little bit larger, while the uninstalled themes could be stacked more easily side by side make them appear to take up less space.
That pattern might encourage and foster to keep more themes as necessary collected idling in the uninstalled themes section. From a security and governance perspective, the uninstalled themes section should have zero to none non-core themes imho. So I agree with the comment from the meetup that making the two-column display consistent across sections for installed and uninstalled themes might be an idea to investigate and explore.

In the following a few thoughts about a possible new direction for the Appearance page @mradcliffe already mentioned in #22. In general, the current page has a rather high cognitive load for processing the contained information and for performing configuration tasks.

Currently, there are two different concepts on the Appearance page. On one hand, you have the Install, Uninstall, and Settings-buttons leading either to a redirect to the corresponding settings page or the direct installation with the Set as default option or the uninstall of the chosen theme. Especially the install/uninstall part is unusual for the Drupal admin user experience, where you are usually unable to trigger a process without submitting a form upfront.
But on the other hand you then also have a form at the bottom of the page spatially and functionally separated, where you can select the admin theme and set one related option. In the forms select list, the user gets presented a list of all available installed themes - admin themes as well as themes not suited for the use as admin themes. A highly demanding task especially for new and inexperienced users figuring out which theme qualifies as a suitable admin theme pick. But also experienced users have to visually process the list and recall and think for a second which theme is preferably used as a front-end theme and which is eligible to be used as an admin theme.

The title of each theme is currently packed with information. First, you have the theme name followed by the version number with no visual separation. In case the theme is set as the front-end or admin theme default theme or admin theme is appended in parenthesis to the title. When the theme is labelled experimental in Core, experimental is added to the parenthesis as well. The whole line is displayed in bold text.
To figure out which is the default theme, the user has to browse all installed theme titles from the left to right (for ltr reading directions) first to distinguish which of those have parenthesis. Then the user has to scan each of those titles in question starting with the name to the version number getting to the parenthesis to figure out if there is the default theme label. In contrast, if you try to figure out what the active admin theme is (in case you are a new user and you are unable to recognize the visual active admin theme) you have two options - scan the theme titles as described for the default theme or scroll to the bottom of the page. Both ways the cognitive load is rather high, requiring a lot of reading and processing of information.

The section titles Installed themes and Uninstalled themes are a bit misleading especially for new users - something I also experienced and struggled with when I've started learning Drupal a few years back and which still keeps me thinking for at least a second. A pattern relevant for installed and not installed themes and modules.
It is great that https://www.drupal.org/project/drupal/issues/2577407 has landed in 9.2.0, that way the install buttons for themes and modules are prepended with Add instead of Install and the install/install problem on the Extend and Appearance pages was gone. After that change, the install/uninstall problem isn't that apparent on the Extend page anymore. You have the list tab containing all the modules installed and not installed - but the uninstalled modules are indicated only by the unchecked checkbox, not by any titles and you have a separate tab to actually uninstall modules.
In contrast on the Appearance page, you have a single page with the section headings Installed themes and Uninstalled themes. The Uninstalled themes section always triggers the association and thought it is a list of themes "removed" from the site as well as from the file system and it is some sort of history of previously installed themes. No real problem as soon as the basic concepts of Drupal are understood but a distraction and possible point of confusion (tbh I have no idea for alternative titles on the Appearance page yet)

I've created now a rough initial mockup to provide a starting point with a few ideas and suggestions for fostering a discussion about a possible new direction for the appearance page hopefully helping to lower its cognitive load and improve its usability.

Make the active Default theme and Admin theme prominently visible on top of the installed themes section. That way, the user can see which themes are selected and active at a glance.

Split up the information previously combined in the title. Leave the name of the actual theme in the title and move the display of the version number out. An option might be to display the version line underneath, as seen in the mockup, or on top of the description. About the placement of the version number, I am not sure what the best choice visually as well as functionally might be (I am not a designer ;) ).
About the details previously contained in the titles' parenthesis, what the default theme and admin theme are is already communicated by the prominent placement, while for the experimental label an introduction of colour-coded badges placed over the theme screenshot might be an idea. One badge for experimental themes, like Olivero and Claro, could be found in the mockup. Additionally, for sub-themes (Gin in the mockup - the corresponding base theme might be displayed in the tooltip and the aria-label) and Core themes (Olivero, Claro, Bartik, Seven and Stark) new badges might be introduced to help to distinguish and label the different types of categories at a glance.

In the context of a subtheme card, I would suggest adding a line underneath the version statement, listing the theme(s) that the selected default or admin theme is depending on. In the mockup, you see Requires: Claro on the Gin card. But in case there is a chain of dependencies the line might be even extended like Requires: Companies base theme -> Zurb Foundation. That way the frontend developer or site building coming onto a project can see if an installed active default or admin theme is a sub-theme based on the badge and on which theme(s) it is directly depending on at a glance. Additionally, it provides an explanation why in the case of the Claro theme as seen within the mockup the uninstall button is missing. The problem of those chained themes was brought to my attention by @andrewozone when I was reviewing the draft of this post with him.

About the following suggestion, I am completely uncertain if it is technically possible at all (I am not a developer), but would it make sense to remove the form at the bottom of the page and move the Use the administration theme when editing or creating content checkbox up to the active admin theme section (see mockup)?
The process previously triggered clicking the Save configuration button might now be run every time an Install and set as admin, Install and set as default & admin, Set as admin, or Set as default & admin-button is clicked or if the state of the Use the administration theme when editing or creating content-checkbox is changed in the admin theme card. That way there wouldn't be a mix of a form and the direct action buttons - the necessity of a form submission would be obsolete.

For the direct action buttons, it might be a reasonable step to introduce drop buttons to group similar actions. I've exemplary expanded two different cases in the mockup. For uninstalled themes, you have one button to install the theme and one drop button to Install and set as default, Install and set as admin and Install and set as default & admin, taking care of the ability that a single theme could be selected as default theme and admin theme at the same time. For installed themes, you have the Settings-button, a drop button for Set as default, Set as admin and Set as default & admin. For none base themes of default or admin themes, there would be an Uninstall-button as well. The default theme has only the Settings-button and a Set as admin-button" while the admin theme has a Settings-button and a Set as default-button. In case the same theme is selected as default and admin theme there should be Settings-buttons only.

To make the selection of the available direct action buttons more intuitive and less error-prone especially for new and inexperienced users it might be an idea to introduce a new key-value pair or extend the type of the themes info.yml. That way theme authors would be able to define if a theme could be used exclusively in the front-end, exclusively as the admin theme or for both scenarios. The number of direct action buttons per theme would be limited. Bartik as a front-end theme would only have an Install, Set as default and Uninstall button as an installed theme, while Seven an Install, Set as admin and Uninstall button. That way you would ensure themes would be used in the way they were designed and designated and at the same time lower the cognitive load for the users.

Edit: Updated the current.png to current_updated.png. Accidentally had a differing list of installed themes for current.png compared to the mockup.png as well as the admin toolbar and the header of section was shown in the screenshot - that was unnecessary. And one additional explanatory note I also forgot to point out. Even though the mockup.png shows Gin as the active admin theme, the rough styling of the mockup is based on Claro. I've just put Gin as admin theme to demonstrate how the Requires section might look.

Usability review

We discussed this issue at #3249152: Drupal Usability Meeting 2021-11-12. That issue has a link to a recording of the meeting.

I am converting this issue into a meta issue, and moving it to the "Drupal core ideas" queue. This issue describes a problem, and we should have a few more actionable issues to implement solutions to that problem.

We had several ideas for individual steps to improve the appearance page, and we should add child issues for these. I am adding the issue tag "Needs followup" to keep track of that. At least the following:

1. Show the Default Theme and Admin Theme at the top of the Appearance page
2. Redesign the cards for the Appearance page
3. Make all form submissions on the Appearance page consistent
4. Let themes describe themselves as admin or default
5. Add full-page previews of all themes

The first three are based on Comment #23 on this issue, and the last is a new suggestion that was proposed during the meeting.

For (1), the idea is to rearrange the cards. Instead of a list of installed themes and a list of uninstalled themes, put the current Default and Admin themes at the top of the page as in the mockup in #23.

For (2), the mockup provides some ideas. In particular, separate the version from the name of the theme. This might actually require several issues: one to provide more granular information to the template, and then one issue for each core admin theme to redesign the card using that data.

The point of (3) is to clean up the mix of immediate-action links and form elements.

We could implement (4) using a new key in the .info.yml file. This issue is related to (2).

The implementation of (5) will have to be decided. Can we automatically generate a sample page for any theme (installed or not)? Or should each theme provide a preview (style guide or sample page) along with a screenshot?

Adding issue links to all follow-ups, looks like they've all now been created.

Swapping #3249371: Enable themes to describe themeselves as admin or default in the info.yml file for #3103375: Let themes indicate whether they work as front-end and/or admin themes.

Back to NW because the issue summary definitely needs an overhaul.

Adding #3103378: Require themes to specify whether they support content editing to the IS as it's very similar to #3103375: Let themes indicate whether they work as front-end and/or admin themes.

added #2591323: Workflow and text for installing themes is confusing to the list of proposed solutions in the issue summary as well as queued it for discussion in an ux meeting.

I've updated the issue summary mainly based on #23. I've also removed the Needs issue summary update tag accordingly. I was then wondering if updating the title to something like "[meta] Revamp of the appearance page" would make sense too? About the child issues in the proposed solution section. Should #3249355: Implement theme preview functionality be removed again based on the last three comments in that issue?

Just filed #3344314: [PP-1] Review the local task and page order/titles/labels under Appearance, which is related to the work here.

During #3344263: Drupal Usability Meeting 2023-03-03 @benjifisher brought up the idea of moving the fieldset for setting the admin theme (at the bottom of the Appearance List page) to the Global Settings form, which I think is a really good idea. The Appearance List page is already doing too much, and this would be a very well scoped change which I think would be a good candidate for the first issue that this meta should look to address.