[PP1] Move "Block layout" from Structure to Appearance

This is now actionable

Adding back subsystem maintainer review tag for the Block module (Tim, Benji)

Adding meta to summary for better clarity.

At 📌 Drupal Usability Meeting 2023-02-24 Fixed , we noted that moving Block Layout to Appearance seems to have broader support, so updating the issue summary to propose that as the path forward.

Also note that the slide deck that was used to gather input from groups of people for 🌱 [meta] Reorganize Block items in the administration menu Active showed Block Layout under Appearance.

Given that this is following the same pattern agreed in previous issues (explained in the updated issue summary) this should be quite a straightforward change.

Re comment #12:

Appearance though might need some changes. If we are moving other things into these tabs, the "List" heading becomes too generic. This should probably be renamed something like "Themes".

I've filed 📌 [PP-1] Review the local task and page order/titles/labels under Appearance Postponed to look at the problem more holistically and as a follow-up to this issue.

Assigning to me to work on POC from call held late Friday in western hemisphere, early Saturday in eastern hemisphere

Here's approach one, just moving stuff around from where it is now

And here's the other approach (second commit in repo)

I'm now leaning towards option 1, although I like the breadcrumbs better in option 2 it required a bit of naffing about

There's a lot more path changes in this one, which has implications too.

The question we probably want to answer is, are people likely to manage things per theme, or per task and use that to group things

i.e. would you manage the settings and block layout for a theme together

or would you manage block layout for each theme, or settings for each theme.

Usability review

We discussed this issue at 📌 Drupal Usability Meeting 2023-03-03 Fixed . That issue has a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @benjifisher, @mgifford, @rkoller, @shaal, and @simohell.

We like the idea of updating the navigation (admin menu, paths, breadcrumbs) of the Appearance pages, as in Comments #22, #23. But in order to manage scope, we want to restrict this issue to moving the "Block layout" page from Structure to Appearance in the admin menu, along with related changes to paths and page titles. We hope to complete this in time for Drupal 10.1.

We are still brainstorming how to rearrange the Appearance pages. We need to settle on a proposal and get community feedback or do some usability tests before we can implement it. We can continue the discussion on 📌 [PP-1] Review the local task and page order/titles/labels under Appearance Postponed , where some of these ideas were already suggested. That issue is already linked to ✨ [Meta] Appearance page is too long and confusing Active , which should be considered at the same time. I do not object to getting that all done in time for Drupal 10.1, but I will be surprised if it happens.

During the meeting, we also opened 📌 Updates in Navigation should come with notifications for users Active . I am adding that as a related issue.

Thanks for the summary Benji! Complementary I've already wanted to post summary of the adhoc feedback sessions i've done a few days ago, but I had too many things in parallel on the plate lately. I've presented the screenshots for the two approaches @larowlan posted in #22 📌 [PP1] Move "Block layout" from Structure to Appearance Postponed (approach 1) and #23 📌 [PP1] Move "Block layout" from Structure to Appearance Postponed (approach 2) at the weekly Lean Coffee Table at the Drupal User group Munich Tuesday before last. For the record the attendees of the Munich meeting were @cawi, @drubb, @franz-m, @it-cru, @jurgenhaas, @martin-mayer, and @pminf. Demographically all attendees are experienced, long time Drupal users - mostly with a focus in backend development.

At first I've walked the attendees through the screenshots, provided a little bit of context in regards of the different approaches, and emphasized that they shouldn't take too much focus onto the micro copy and just focus on the functionality and how pages are structured in each approach. I try to sum up the result as good as possible. But during the ad-hoc session I had to take notes alongside with several people talking alternating- not the easiest circumstances where the translation of colloquial expressions complicated things further afterwards.

The initial reaction was that everyone was drawn towards approach 1. It felt more familiar, more intuitive and accessible. Grouped by task it felt closer to the patterns attendees were used to. In contrast the first impression for approach 2 something felt off and there was a certain antipathy. It felt new and unfamiliar. Block layouts weren't something people were associating with themes. But after some conversations and reflecting about the topic approach 2 slowly started to sink in and grow on everyone.

During the discussion it was noted that site builders have to interact way more often with the layout builder settings than with theme settings. those would be easier and probably with one one click less accessed in approach 1 compared to the current plan with approach 2. it was also pointed out that potentially the initial reason why everyone was drawn towards approach 1 is the laziness and dislike changing workflows and approach 1 has the advantage of minimal change. They suspected that the change will be way more significant for experienced long time users who have to adjust their muscle memory. For new users the group recognized the change is way more reasonable and straight forward helping them to understand the concepts in Drupal way more easily. Because they recognized meanwhile that approach 2 is semantically way more logical. in particular the breadcrumb paths in approach 2 are way more straight forward.

so the vote shifted from everyone voting for approach 1 to everyone voting for approach 2 except one person who became at least neutral towards approach 2. The person was just worried about change and the need to learn new concepts after years and years - which is a reminder to the aforementioned point about muscle memory.

In the context of approach 2 the group had only one requirement. the block layout page for in particular the default theme should be reachable as fast and as direct as possible. getting to the appearance page and clicking the block layout button for the default theme is one extra click compared to clicking the block layout menu item under structure menu item currently. but ✨ Adjust to the changes introduced reorganizing Block items in the administration menu Needs work would solve the problem for the time being until ✨ [Meta] Appearance page is too long and confusing Active advances including the changes suggested in approach 2 and iterating based on that. but the reachability for the top task "get to the block layout page as fast as with as few clicks as possible" is a top priority for them.

In the end of the session @jurgenhaas had an excellent follow up idea for approach 2 - basically adding a third tab for layout builder layouts. it would be logical addition to each theme card. and tbh imho a good place to provide a central place to present the list of available layouts and layout overrides for nodes as suggested in #3325039: Improve the overview of the list of available content types with a layout and layout overrides for its nodes → . semantically it would be an excellent fit for the appearance page and the theme cards in particular. in the issue there wasn't a concrete idea yet where to place those but the theme cards seem to be a viable destination.
in addition to that another participant came up with the idea, which was already voiced in one of the discussions in regards of approach 2 in here, to move view modes out of structure and add them into appearance and the theme card tabs.

Two days after the lean coffee table in Munich I've briefly presented the two approaches to the Drupal Dojo in Austin. That night was a bit busy and the conversation quickly got derailed and shifted to another topic but the initial reaction of the attendees was that none of the approaches really jumped out and approach 2 was sort of "obscure" on the first look. But it was just a brief first look without the time to let the new concept sink in that happened in the munich group.

Based on the discussion during the usability meeting referenced in #24 📌 [PP1] Move "Block layout" from Structure to Appearance Postponed i've iterated a bit on the idea @benjifisher came up with, adding a tab for every installed theme on the appearance page. It was already noted during the meeting that for some sites with many themes installed the tab bar might become crowded. I've thought maybe it might be an idea to simply show a tab only for the default and another tab for the admin theme. I've create a quick mockup:

i've presented that rough idea to the munich group last tuesday to get some initial feedback. the idea moving the overview page for managing themes (like install, uninstall as well as defining the default and admin theme) got a collective thumbs down. having the themes hidden in settings in a second level tab menu was very much disliked. that page should stay more prominently. in addition it was noted that displaying only the default and admin theme as tabs might be problematic in the case a site is working with a theme switcher. but in general the ideation in that direction, moving the theme management into settings, wasn't that well received in general.

one idea how to integrate the feedback from the previous comment and a potential direction that could work for ✨ [Meta] Appearance page is too long and confusing Active might be to simply move the option to set the default and the admin theme into a secondary tab inside appearance settings page. that would solve #3249379: Make all form submissions on the Appearance page consistent → .
a tab would be created on the appearance settings page adding two fieldsets each containing a select list (one with all installed theme suitable for the front end and one with all installed themes suitable as admin themes #3103375: Let themes indicate whether they work as front-end and/or admin themes → ). that way you would still have the theme cards for all available and installed theme on the appearance main page. each theme card could only need two buttons - one for getting into the theme card view described in approach 2 and one button to install/uninstall the theme. i could post the idea over in the appearance meta or the appropriate child issue if the idea sounds reasonable. but thought it made more sense to post it in here due to the context with the previous conversations in regards of approach 1 and 2 and the subsequent feedback sessions with users.

First off, I've been thinking about this more, and of the two approaches presented in #22 (option 1) and #23 (option 2), for this issue specifically, I am leaning more towards that we should just do option 1, because the change is smaller in scope and doesn't result in a significant restructure of the Appearance section, therefor it will be easier to get this done before 10.1.

However, I do ultimately think that something like option 2 is better in the long-run, but it is clear from recent comments and discussion, that it opens a much wider discussion around the structure of the Appearance section, so in the interest of keeping the scope tight I think we should consider option 2 in a follow-up issue and within the context of ✨ [Meta] Appearance page is too long and confusing Active where it can be properly prioritised as part of that wider reorganisation.

This approach seems to the consensus from the recent usability meeting as well, so I would suggest we proceed with Option 1 in this issue, and file a follow-up issues for exploring Option 2 further.

Secondly, I'd like to thank @rkoller for presenting this at various meetups, there are some really good suggestions and thoughts in your outputs that we need to properly consider (in follow-up issues, probably as part of the wider appearance reorganisation), but some specific things I'd like to pick up on just now:

the block layout page for in particular the default theme should be reachable as fast and as direct as possible

Agree, I think in the context of doing option 1 just now, that would mean that when you click on the "Layout" local task, you first see the block layout of whichever is the default theme. Additionally, this would be further addressed by a "Layout" button being on the theme card.

adding a third tab for layout builder layouts. it would be logical addition to each theme card. and tbh imho a good place to provide a central place to present the list of available layouts and layout overrides for nodes as suggested in #3325039: Improve the overview of the list of available content types with a layout and layout overrides for its nodes → . semantically it would be an excellent fit for the appearance page and the theme cards in particular.

The problem is that the layouts that are available in Layout Builder are not provided by individual themes, modules provide Layouts, and the Layout Discovery module is used to pull them together, they are completely independent of the installed/default theme. So I'm not sure it would make sense under Appearance. However, I do agree with the general ideal that people would benefit from having a way of more easily discovering which Layouts are available without needing to open Layout Builder, partly because other modules can use the same Layouts for other purposes.

in addition to that another participant came up with the idea, which was already voiced in one of the discussions in regards of approach 2 in here, to movedisplay modes out of structure and add move them into appearance and the theme card tabs.

Again, I'm not sure I agree with this, because display modes are entirely independent of the theme, they are defined in configuration and are created in the user interface. If anything they probably belong under Configuration.

Based on the discussion during the usability meeting referenced in #24 i've iterated a bit on the idea @benjifisher came up with, adding a tab for every installed theme on the appearance page.

This may be a good option but I think it depends on what ultimately happens with Option 2 and the wider reorganisation effort in ✨ [Meta] Appearance page is too long and confusing Active , for instance if we go ahead with Option 2 as is then that wouldn't work, but if instead we incorporated this idea into option 2, whereby each theme has a tab (primary local task) and the "Settings" and "Layout" tabs are secondary local tasks, then that could work. This is where we would benefit from a dedicated issue to discuss Option 2 and can look at this idea as part of the solution.

As a final thought, I wonder if the Layout local task tab should be called "Block layout", rather than just "Layout", my thinking here is inspired by something that was said at the recent usability meeting about how we could better guide users to the new locations of pages after they are moved. Keeping the page/tab title as "Block layout" helps with that because it provides consistency, in that the user is looking for the block layout page, so by keeping the name of the tab consistent with what the menu link under Structure is currently named, we make it easier for users to find it.

I think I was one of the people who originally proposed naming it simply "Layout", because in the future Layout Builder could replace the current region/block layout interface; But if/when that happens it might then make sense to shorten the name of the tab to "Layout", until then I think "Block layout" is better.

The votes from the Sydney meetup are in are in:
Option 1: 8 - Layouts nested under appearance
Option 2: 2 - Layouts nested under the theme
Option 3: 1 - No change = keep it in structure

So option 1 was the winner.

The tradeoff was between depth and encapsulation. In general people thought it would be quicker to get to if it was at a lower depth. The two votes for having it in the theme considered encapsulation to be a sronger organising principle. The one vote for no change was from a developer who didn't want to change his ways. In general moving it to apopearance and out of structure was considered a good thing.

Thanks @pameeela @skipper-vp @marji @andrekakos @jct321 @jimik42 @richo_au There were a number of others there but I was unable to find user accounts for them. My apologies if I missed you out in this list.

benjifisher → credited andypost → .

benjifisher → credited legolasbo → .

benjifisher → credited MattA → .

I am updating the issue summary and assigning this issue to myself. If I do not make progress in the next 3 days, feel free to un-assign me.

I intend to follow the original scope of this issue, moving Block layout under Appearance (changing the path, making it a local task, and updating the Administration menu). I think we can do that in time for Drupal 10.1.0, and I would like to get it done along with 📌 Move custom block types admin link to admin/structure Fixed and ✨ Move Custom block library to Content Fixed .

I support the changes discussed in Comments #21 to #27, but I think they are out of scope for this issue and unlikely to get done in time for 10.1.0. I would like to see that discussion continue somewhere else, perhaps on the parent of this issue.

I notice that @smustgrave closed #2532054: Move the block layout page to Appearance → as a duplicate of this issue. (I wish I had found that issue when I opened this one.) I am transferring credit from that issue to this one.

I am adding a little detail to the issue summary (all the child pages).

It turns out that there are 9 routes that need to be updated (Block layout and 8 children). Only 7 of these need BC redirects, since two (enable and disable) require CSRF tokens, meaning we do not want to support saved links to these pages. Two of them (for the modal forms when adding a block to a region) need a little extra work to preserve the region query parameter. (I hope I did not miss any others that need to preserve query parameters.)

I think that MR 3770 is ready for review.

The diff is +460/-156, but a big chunk of that is one commit in the tests (+135/-135), replacing admin/structure/block with admin/appearance/block. From the commit message:

• Include one test module as well as many test classes.
• Do not change admin/structure/block-content nor admin/structure/block/block-content.
• Do not change fixtures.

The other big commit (+303) does what I described in Comment #33.

I am adding a "Remaining task" to the issue summary: update the change record (CR).

A few of the Help Topics mentioned "Structure > Block layout" and needed updates, but block_help() just used the route, so it is clean.

On the other hand, block_help() refers to Managing Blocks → , which will need updates. (It already needs some updates because the screenshots use Seven and show the Block layout page for Bartik and Seven.) What is a good way to keep track of that? Is that what the "Online documentation" field in the CR is for?

I am updating the "User interface changes" section of the issue summary.

I include links to screenshots of the parent pages (Structure before and Appearance after), but I do not think it is worth showing them in-line.

The failures on https://www.drupal.org/pift-ci-job/2632751 → are unrelated.

I double checked that the last commit only does what I meant it to do, and I am queuing a new test.

I wrote 7 different redirect functions (in Controller classes) for this issue. That is kind of ugly.

While working on 📌 Move block content edit and delete routes under admin/content/block to improve IA for editors and fix breadcrumbs Fixed , I noticed that I had created redirects for routes defined by the block_content module, but not related paths defined by other modules (field_ui, content_translation, user). We have a similar problem with 📌 Move custom block types admin link to admin/structure Fixed .

Maybe I will start on this issue by consolidating the redirect functions. If that works, then we can use it as a model for other cases, so that modules like field_ui can add BC routes without having to define their own redirect functions.

Looking at the page controllers, I see that there are more than I realized that make use of query parameters. (See Comment #33.) At least these:

• BlockForm::form() checks weight and region query parameters.
• BlockListController::listing() calls BlockListBuilder::render() which (a little deeper in the call stack) uses the block-placement query parameter.

In short, it is beginning to look like a good idea to preserve the query string in the redirect. Is there any danger in doing that?

I updated the change record, so I am removing that issue tag and updating the "Remaining tasks" in the issue summary.

It looks as though I forgot to update the tests after consolidating the redirect controller functions.

I updated the deprecation message in the test, and I rebased on the current 10.1.x. Back to NR.

The latest test failure → is from Drupal\Tests\ckeditor5\FunctionalJavascript\MediaTest, so it is probably unrelated. I am leaving the status at NR.

Tested this like we did the others.

Verified the link has been moved.
Went to the old URL and got redirected correctly
You have been redirected from /admin/structure/block. Update links, shortcuts, and bookmarks to use /admin/appearance/block. appeared correctly.

Breadcrumbs appear correctly

Added a block and verified everything redirected back to the layout correctly.

Think this is good.

@smustgrave:

Thanks for the review!

You mentioned the testing steps. Thanks for that. But you did not say anything about code review (the "R" in RTBC).

larowlan → credited EclipseGc → .

larowlan → credited JCT321 → .

larowlan → credited jimik42 → .

larowlan → credited marji → .

larowlan → credited pameeela → .

larowlan → credited richo_au → .

larowlan → credited rocketeerbkw → .

larowlan → credited skipper-vp → .

Left a couple of comments on the MR, but this is looking great @benjifisher

Would be good to get a +1 from a product manager and @tim.plunkett (subsystem maintainer)

Updating credits for those involved in UX team calls and Meetup demos around this change

larowlan → credited Arctic.Cheetah → .

@larowlan:

Thanks for the review! It may be a few days before I have time to update the MR.

In order to manage scope, I was thinking of moving the helper function to a trait in 🐛 Create BC redirects for children of changed paths Fixed . That issue would deal with children of paths that we have already updated in other issues. But I can work on it in this issue if you think that makes more sense. Do you have any suggestions for where to add the trait?

I was also thinking of generating the redirect response from the Request object, changing the path, instead of using ControllerBase::redirect(). If I do that, do you still think we need test coverage for the query parameters?

@benjifisher I think a follow up makes sense as there's a few moving parts there that we should take our time to get right.

Re the test coverage, I think it would be good to add explicit coverage either way.

I added test coverage for the query string. I could not think of a good reason for not testing the query string, so I added two query parameters to the test instead of varying it in the data provider.

While I was doing this, I started wondering how to handle the destination parameter. I added a comment to 🐛 Create BC redirects for children of changed paths Fixed , but maybe I should strip it here.

I hacked drupalci.yml so that it will run tests just for the block module because I want to confirm my updates to the test. I will revert that and add a commit for the last part of Comment #56.

Are the changes to vertical tabs js in the MR expected?

Are the changes to vertical tabs js in the MR expected?

Ack, no! I had a stray commit in my local branch from testing an unrelated issue. Thanks for asking!

Hm, I think it could make sense to move the block admin UI to appearance but not as a drop-in thing I think. To elaborate, I have mixed feelings about this UI currently listed as the "after" state of the proposed change:

It mixes various things on the same level I think. List of what and Update of what and Settings of what? Should blocks be logically a setting of the theme? The whole section is not laid out like our other parts of the admin UI. You have a "List" page to pick a theme, then have theme specific tabs under both the blocks and the settings tabs. That's not how content types work or menus or views or whatever else. So I am not sure just moving this around is quite putting things into place? I think that is where the potential separate "Default theme" and "Admin theme" tabs were experimented with in one of the above directions, to flip it around and put stuff under them?

It could also be an answer that this interaction model is better for things, but I am not sure we would reorganize content types to have "Fields", "Forms", etc. high level tabs where you pick content types below that to edit fields/forms for. We do it the other way around where you pick the content type and then do its fields or pick a content type and then do its forms.

Here I think we would be mixing things that are highest level (global settings, update) with stuff that can only be on a theme specific level (blocks and theme specific settings).

@Gábor Hojtsy I agree with everything you've said there, and that was an idea that we discussed in Slack and in this issue. In comment #27 I summarised that while we do think that ultimately the approach you described is better, in the interest of scope we felt that simply moving the block layout to appearance in this issue was easier, as it was starting to open a whole can-of-worms around the structure of the Appearance section as a whole. The main advantage of not doing that bigger restructure in this issue is that, once Block Layout is in Appearance, it allows us to consider that broader reorganisation in a more holistic way as part of ✨ [Meta] Appearance page is too long and confusing Active . That issue has various child issues which propose different changes/approaches, so I think it's important for us to consider everything together.

Additionally taking this intermediate step could be a smoother transition for users, for instance in 10.1 we get them used to the Block Layout being under Appearance, then in 10.2/10.3 we start a wider reorganisation of the Appearance section to make it much more consistent with Content Types, Fields, etc, and also easier to navigate around. I am very much in favour of us ultimately getting to a position where Appearance behaves like Fields, where you have the list of themes and then under each theme tabs for Settings and Layout.

I agree with Comment #64. That comment focuses on the next steps, rearranging the pages under Appearance in the admin menu. We already decided not to tackle that project for Drupal 10.1. I just want to add one point: the reason we put Block layout next to Settings is that those are the two tabs that have sub-tabs for each enabled theme.

I mostly want to recap the changes that have already been made, since this issue is the last major step in the plan to rearrange the Block pages. I think the change record → has the most concise summary, and of course the parent issue describes the entire plan.

Until Drupal 10.0, we had these pages/tabs in the admin menu:

• Content
• Structure
  • Block layout
    • Custom block library
      • Custom block types
• Appearance

The current state is the following. To make the comparison easier, I am keeping the old names.

• Content
  • Custom block library
• Structure
  • Block layout
  • Custom block types
• Appearance

That is, we have already moved the child and grandchild pages away from Block layout. That makes it less useful as a direct child of Structure, and I do not like having Block layout and Custom block types both be direct children of Structure.

I would also like to point out that we have discussed the plan in the Usability team and we have solicited feedback at several events. The idea to move Block layout under appearance was the last "puzzle piece", and it is very popular. Some of that research is documented on this issue, and some is on the parent issue.

I think those are compelling reasons to go ahead with this issue despite the temporary inconsistency. I think the block types being moved was not about an 80% feature but the block library and block layout are 80% cases (given layout building not yet being there to replace this). I also agree the block layout being where it is now makes not more sense than it being in appearance, so leaving it there as-is now is also not a good solution. So let's go with this! I sincerely hope we can land on an Appearance section reorganization in 10.2 to make that area easier to navigate though.

I did not (and don't plan to) review the code, however signing off on the UI change itself now. Subsystem maintainer review is still needed it looks like.

I have some user interviews scheduled for next week to validate Field UI related changes. I'm planning to include this in those tests too to make sure that the current approach is discoverable. I want to make sure that users who are not familiar with this change, naturally gravitate towards the appearance section, at least eventually.

We conducted usability tests with 5 users who were all experienced Drupal users. Generally, these users were very quick to recover from small unexpected things happening with Drupal (less than 10 seconds). However, when presented with this change, in average it took between 1-2 minutes, some of them requiring several prompts to continue looking elsewhere. Only one of the users clicked "Appearance" as part of a process where they went through all of the Toolbar links. Rest of them skipped "Appearance", and discovered where "Block layout" is by some other workaround, such as using contextual links and inspecting the breadcrumbs.

Once users discovered that "Block layouts", it kind of made sense to them that it would be displayed under "Appearance". This probably adds to the evidence already provided by some of the earlier research.

However, it seems that users are very used to having "Block layout" under "Structure", and moving it leads into some disruption because they don't naturally gravitate towards "Appearance". Given that this impacts navigating to one of the most important pages on Drupal, I'd recommend looking into a solution that addresses this in a way that doesn't lead into as much disruption. I'm not too keen to a specific approach but something like keeping both links temporarily in place could help.

We have known all along that this is a disruptive change. I still think that finding the changed location will be hard only once, so I am not sure that the testing reported in #68 means that we have to make changes.

I pushed a new commit, which adds a link under Structure (the old location) in the admin menu. This new link goes to the redirect route already added in this issue, so the page loads with the same warning message:

You have been redirected from /admin/structure/block. Update links, shortcuts, and bookmarks to use /admin/appearance/block.

Also, I set the title attribute to "Use the link under Appearance.", so that text appears if I hover over the link.

It is easy to change the link text ("Block layout BC"?) or the title attribute. Changing the warning message would be more work.

The site administrator can disable this link from /admin/structure/menu/manage/admin once everyone has learned about the change.

The failing test passes when I run it locally, so I am asking the testbot to try again.

I was going to suggest the exact same thing Benji, adding a link under Structure :)

As Benji noted, we know going into this whole reorganisation effort that that these changes were going to be disruptive, arguably moving Block Content from Structure to Content could also result in the same confusion. In an ideal world people would read the release notes for new releases and so would be aware of any changes, but obviously that's not always the case. I don't think that should deter us from making this kind of changes once in a while, people will adjust and adapt, and I think now a days a lot of people are used to companies like Apple, Google and Microsoft moving things around in each update of their operation systems. The way I've looked at all of this is if the change ultimately has a net positive impact then it's worth doing, but we should do our best to help users along the way in that transition. So adding things like redirects and links to the new locations is definitely a good thing.

I've suggested some alternative wording for the link description text.

Follow-up thought, it would be great to get this committed before alpha is tagged, because of the path changes. So what if we move the BC-link to a follow-up issue, as that could go in at any point up until release?

Moving things around on its own is fine, and I'm not against that. It's mostly about how intuitive the change is for users. Moving some things is more disruptive than others, and therefore when we move things around, we need to look them case by case basis.

Moving something from "Structure" to "Content" is likely less disruptive than moving something from "Structure" to "Appearance". The reason for this could be that "Appearance" tends to be a section that users only visit once in the beginning of the process, and never visit that later. In fact, people were looking for the "Block layout" link under both "Content" and "Configuration" sections, but not under "Appearance". After all, it's about how do people navigate the UI intuitively and how big of a disruption it is. In this case, it seemed quite severe and it's an UI that is accessed pretty commonly, therefore I recommended a different approach for this.

The change that happened with Block Content is a different case and is likely less disruptive than this, since users tend to visit the "Content" section more often than "Appearance".

@lauriii Yep totally agree with you, we have to asses each change individually, and I share your thoughts around the move to Content was a more intuitive move compared to Block Layout moving to Appearance in this issue, and obviously your user research highlights that to be the case.

@Benji thanks for making the change to the description text I suggested, if @lauriii is happy with the change then looks like this can go back to RTBC.

benjifisher → credited akalata → .

The alpha release is out now. I am not sure whether this issue is eligible for the beta release. :-(

I talked about this issue at MidCamp with @akalata and Jen Stein (d.o username??). If we are going to add the "temporary" link under Structure, then we agreed to add "(legacy)" to the link text, in order to distinguish it from the "permanent" link. We also agreed to use @Aaron McHale's text, with a little editing: "Block layout is now under Appearance. This link will be removed in a future update."

This is what the link looks like on the Structure page:

Yeah I'm happy with those changes.

Thought about it a little more, I wonder if the meaning of "legacy" in this context be misinterpreted to imply that Block Layout itself is legacy and will potentially be removed.

Applied the MR and verified seeing the legacy change.

But seeing this for the first time (which I have) I had the thought #78 had. Maybe we should just be blunt and say "Legacy Link"

I updated the link text. Here is an updated screenshot:

Thanks!

Just to note that I've suggested we discuss the "legacy link" at the usability meeting on Friday.

I've run 5 user interviews with the new approach using legacy link. It's working much better than the earlier iteration. However, the legacy link caused a lot of hesitation with all of the users, and all of them first clicked "Block types" link instead. Everyone was able to get to the block UI eventually after some exploration without additional prompts.

I have not updated the MR, but here is another suggestion for how to present the legacy link. Keep the same text, but add an icon.

Having two links with the same link text is bad for a11y. We could add some visually-hidden text to the "legacy" one. Or we could decide that it is OK to have the same text twice, since both links go to the same place. (One gets there using a redirect.)

This screenshot also shows the warning message provided by the redirect route.

Personally for me I think it should be visually hidden. We don't use icons for any of the other links and kinda looks weird.

@benjifisher,
Tracked down Jen Stein's username jen.stein

benjifisher → credited jen.stein → .

Thank you, @generalredneck and @jen.stein!

Discussed this with several people at DrupalCon Pittsburgh: we're postponing this until we have results from 🌱 Restructure the admin interface Information Architecture Active where we're reviewing the whole admin menu Architecture Information. This way we'll be sure we address the concerns around the confusion with the Appearance section purpose.

I am adding 🌱 Restructure the admin interface Information Architecture Active as a related issue, and I am also adding it to the "Remaining tasks" section in the issue summary.

Even though this issue is postponed, I am going to update (simplify) the MR now that 🐛 Create BC redirects for children of changed paths Fixed has been Fixed.

I updated the change record (CR) Block management pages have new paths and menu items → , removing references to this issue. This issue will need a new CR, so I am adding the tag for that.