[PP-1] Review the local task and page order/titles/labels under Appearance

in regards of point 1. i agree as long as the top level menu item appearance was just about themes, the term list wasn't perfect but made "sort of" sense. with the move of the block layout page into appearance, themes might be the clearer pick. or are there other alternatives? but definitely a +1 for renaming the term list

In regards of point 2, i've posted a suggestion in the "rename the block terminology in the administration menu issue": https://www.drupal.org/project/drupal/issues/3318549#comment-14936752 📌 Rename Custom Block terminology in the admin UI Fixed . I would vote on renaming the title from Block layout to Block placement instead. It is slightly longer but from my point of view clearer what the actual task is that is taking place there. as mentioned in the linked comment the term layout i usually associate with the ability to actually decide about the layout of something and its actual design. but on the block layout page you actually decide where you want to place something. and if you take a look at the help text on the appearance page the first two words already provide the queue what the more suitable term might by leading in with "block placement" imho

in regards point 3. i am not sure. i agree that update shouldnt be placed before settings. but i wonder with the currently called block layout tab, being nitpicky, what does settings actually refers to? what does appearance stands for now and what would its settings be about (an observation just based on the naming - for me personally it wouldnt be clear). i wonder would another order be more logical? 1. themes 2. settings (because those settings are in the context of themes - theme settings would be clearer) 3. block layout (or block placement) 4. update

and in regards of the update tab. the work of the automatic updates initiative has also to be taken into consideration. they have created ux designs #3227564: Automatic Updates UX Designs → about potential changes to the admin interface that should also be taken into consideration or at least kept in mind.

I would vote on renaming the title from Block layout to Block placement instead.

Yeah I do like "Block placement" better than "Block layout". Have added that as an option to consider as well.

i wonder with the currently called block layout tab, being nitpicky, what does settings actually refers to? what does appearance stands for now and what would its settings be about (an observation just based on the naming - for me personally it wouldn't be clear).

Yeah "Settings" could also be quite vague, maybe "Theme settings"? If the first tab was "Themes", then the second was "Theme settings", that could make the relationship really clear. "Theme settings" is technically shorter than "Theme configuration" and may be more familiar to users, who are used to seeing the term "Settings" on computers and phones these days. Worth keeping in mind actually for 🐛 Settings vs. Configure for UI text? Active .

Of course "Settings" is the shortest of them all, and we do follow the philosophy of less is more, but that should never come at the cost of the users ability to understand what the relationship is between items.

the work of the automatic updates initiative has also to be taken into consideration. they have created ux designs #3227564: Automatic Updates UX Designs → about potential changes to the admin interface that should also be taken into consideration or at least kept in mind.

That is a great point, if there is a more unified "update" UI then that could remove the update local task and I would fully support that idea!. I have added that as a point to the summary.

Thinking about it more, what if we were to follow the pattern of Field UI and completely flip the navigation pattern. So isntead of having local tasks for items like "Settings" and "Block layout", with tabs for each theme under them. Like how with bundles, you edit a bundle and within the bundle settings you have the "Manage fields", "Manage display", etc. local tasks.

If we followed that pattern here, that would mean that the "Settings" link on each theme would take you to a page that had local tasks for "Settings" and "Block layout" for that specific theme.

So just to quickly mock this up:

Here is the Appearance page, but with no local tasks:

You click the "Settings" link for Olivero, you get to the same theme settings page, but the local tasks now appear and are specific to Olivero, with "Theme settings" and "Block layout". Much like with configuring a bundle or field you stay within the context of Olivero when navigating between the local tasks. Also notice I changed the Breadcrumb to reflect that the next item up is back to the Appearance page.

This could actually be a much better pattern, because let's say when you install a theme, you go into the settings screen, you have access to everything relevant there.

This could also be a good pattern for some more complex themes which try to cram a lot into the Theme Settings form, this opens up the possibility for those themes in the future to add their own local tasks and simplify their theme settings. That would probably require some changes in how themes set up their settings though, but I think it would be a huge win from a UX perspective.

The only thing I'm not sure is what happens to the "Global settings" form, but I feel like we could find a suitable home for that, maybe that has a button in Appearance. Maybe it even moves out of Appearance completely and into Configuration, which is where you usually expect to see "global" settings anyway.

I hadn't properly closed the <ul>.

Moving to 11.x as per https://www.drupal.org/about/core/blog/new-drupal-core-branching-scheme-... → . If this can only be done in a major version, then a [11.x] title prefix should be added and a "Major version only" tag too.

I actually don't remember why I created this against 11.0.x, it was probably because of the huge potential for BC-breaking URL changes.

But now that we have 🐛 Create a redirect for the new Block types path Fixed done which established a pattern for making BC-compatible URL changes in the admin UI, I don't see a clear reason that this can't be done in a minor.

So moving to 10.1.x.