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

I'm very much in favour of moving it under Appearance, because:

1. Block Layout has a tab for each theme, in the same way that the Theme Settings section does (as @benjifisher noted in comment #2).
2. When installing a theme, one of the first things you might do is go to the Block Layout to customise the blocks in the regions.
3. The Block Layout is deeply tied to each theme, the theme defines the regions and there is no prescribed regions that a theme must define (except maybe "content", I'm not sure), but the available regions can vary widely by theme.
4. Block Layout configuration is organised per-theme, and themes typically ship with a default set of blocks pre-configured in the most appropriate region for that theme.

I'd also raise the following additional points/advantages of moving it out of Structure:

1. If the other related issues end up moving the other parts of the Block system out of the "Block Layout" section ("Custom Block Library" re-named and moved to "Content", "Block types" moving up a level, etc), then that makes doing this issue a lot easier. As a side-note, now that we have Layout Builder in Core, Blocks can be used as part of content and not just in regions, meaning it's no longer just administrators using blocks, site builders and content creators/editors can also use Blocks.
2. This helps give the Structure menu a clearer purpose, and makes it more about configuring bundles, fields, displays, etc. Which further aids in the reorganisation and rationalisation of the admin UI.

I've presented the current plan for moving and untwining the block related pages in Core at the Drupal Dojo Austin to yesterdays attendees @rocketeerbkw and @arcticcheetah. The plan was as agreed in https://drupal.slack.com/archives/C1AFW2ZPD/p1666965008595329 to get some general feedback about the plan by a diverse number of users.

In addition to the general thumbs up for the different steps there were the following comments specific to the block layout screenshot (i've went with the suggestion @aaronmchale made in #3):

the first reaction during the video call, the icon (the brush) and the name (appearance) is more associated with theming and colors and it wasn't expected to find something like block layout there. but it wasn't necessarily expected under structure or configuration either. the conversation about block layout went on for a little while. @rocketeerbkw summed and rephrased the gist about it one or two days later via Slack. The write up:

1) How is content arranged? Does my site have a header/footer? One sidebar or two? Where is the main navigation? Should I put the newsletter signup above or below the comments? Does my gallery put captions below the image or is it only show in a popup? Content editors can add a two column layout for articles, but not for blog posts. Landing pages can have any layout. Hide or show the site logo? Should content fields be shown or hidden? Hide the sidebar on mobile. (I'm sure I'm forgetting a lot....)

2) How does content look? What theme should I use? Use an admin theme or not? Is the navigation a horizontal drop-down type or a verticle nested <ul> type? How big are <h1>? What's the main font? How much spacing do I put around images? Font size should be bigger on mobile. Are content editors allowed to bold or italicize text? Do tables have thick/thin/no borders?

I think that both #1 and #2 can be considered to be part of the appearance of a Drupal site. Right now, most of what happens in the Appearance section is related to "how does content look," and the majority of that is all done in code via the theme. There are a few things related to "how is content arranged" in the theme settings though. I think this is the reason that putting more stuff from #1 (like block layout) under appearance feels like both wrong AND right.

I think it would be OK to say that Appearance should mean both arrangement and styles. The brush icon represents only "style" so we can change that, but we can keep the word "appearance."

Combing #1 and #2 but using a word other than Appearance is OK too. I just think that Appearance can mean both IMHO, but we're just used to it meaning only #2 thus far so it feels "wrong" to put #1 in it.

Thanks for taking the time to present this @rkoller, some other thoughts (trying not to repeat myself in #3):

1. "Appearance" is for how the whole site looks and feels, how the site is laid out (do I want a sidebar, do I want a logo, what do I want in my header, footer, sidebar, etc).
2. "Structure" is for how I want content to be... structured, or in other words, what is the information architecture of my site (how many content types do I want, what information should those content types store, how much of that information should be structured content vs freeflowing, do I want reusable content, etc)
3. "Content" is for the specific piece of information/assets that I want my site to contain (the individual pages I want, the induvial media assets, the information I want to reuse across pages - aka blocks, etc).

There's a nice hierarchy there, and there's a reason I made that an ordered list, because you can quite easily map roles onto each of those:

1. Administrator, Site builder
2. Content designer/manager, information architect
3. Content editor

This is all very relevant to #2755613: Restructure the admin interface Information Architecture and #3203618: New “content creation” menu proposal, because what we're doing here is basically taking one step closer towards that, we're essentially edging closer to a world where the admin UI is organised by personas and user stories.

Think this will be a great feature that will make blocks more usable for the user. So stamp of approval

I'm plus one for this too

In agreement with some of the thoughts in rkoller's comment here. To me it seems a bit unexpected for block layout to be under the Appearance menu, particularly when there's a menu option right next to it called Structure. Initially my thoughts for appearance is that it's more related to styles, the look and feel of the content as opposed to the arrangement of the content. Maybe there's a more appropriate name that could be used for that menu, or at least the icon changed.

re #5 the points @rocketeerbkw made weren't meant to contradict the structure you've lined out in #5 (at least how i understand it ;) ). he just took a more granular look at the appearance page and what the current available options are - that boiled down into the two categories in #4. so he is actually making the case and supports your suggestion moving block layouts under appearance. the only detail that might be debated is if it might be necessary to change the icon and or the label appearance to something else.

I've presented the current plan for moving and untwining the block related pages in Core at the weekly Lean Coffee Table at the Drupal User group in Munich to @drubb, @franz-m, @it-cru, @jurgenhaas, @martin-mayer as well as to the Fox Valley Computer Professionals attendees Anthony E. Scandora, @bsnodgrass, Sally Gradle, @TBone242.

Right at the beginning in one of the sessions one attendee told an anecdote. He works mostly with decoupled sites these days. Recently he had to help someone getting to the block layout page. He struggled to remember and find it. His first pick lead him onto the appearance page.

One attendee noted that the appearance page is theme specific. It is really related to theme regions therefore the appearance page is also considered the right destination for the block layout page.

Someone else stated that custom blocks are content entities. The "when" and "where" those custom blocks are displayed is defined in config - so the appearance page as an intersection is actually a good fit for the block layout page.

so there was an overall thumbs up for moving the block layout page into appearance.

Generally, I think this is OK. Things should be centralised, but there isn't one way to centralise things. So yes having one place where you go for most block-related things makes a sort of sense, wherever it happens to live. Having one place you go for Structure, Content or Theme specific functions is another way, and I'm fine with that.

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".

Think this is postponed until we move block types and block library out from under it

So the block types have been moved. And confident #2862564: Move Custom block library to Content could be close.

This ticket is next in line. What's the consensus for where we want to move the block layout

The way I use blocks I'd only ever be placing things like menu, breadcrumbs, branding etc which all make sense to be tied to the theme configuration, so +1 for 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 #3342717: Drupal Usability Meeting 2023-02-24, 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 #3318110: [meta] Reorganize Block items in the administration menu 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 #3344314: [PP-1] Review the local task and page order/titles/labels under Appearance 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.

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(approach 1) and #23(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 #3317639: Adjust to the changes introduced reorganizing Block items in the administration menu would solve the problem for the time being until #2860419: [Meta] Appearance page is too long and confusing 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 movedisplay modes out of structure and add move 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 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 #2860419: [Meta] Appearance page is too long and confusing 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 #2860419: [Meta] Appearance page is too long and confusing 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 #2860419: [Meta] Appearance page is too long and confusing, 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.

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.

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

@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.

It is also necessary to update https://www.drupal.org/docs/core-modules-and-themes/core-modules/block-m... (The two Block layout related screenshots need an update as well as the path Administer > Structure > Block Layout.) as well as https://www.drupal.org/docs/user_guide/en/block-concept.html. Added the needs documentation tag

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

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 #2860419: [Meta] Appearance page is too long and confusing. 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 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.

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.

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"

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.

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

Discussed this with several people at DrupalCon Pittsburgh: we're postponing this until we have results from #2755613: Restructure the admin interface Information Architecture 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.