Eh… are you sure about this layout?
It makes finding right component really hard. And looks… really restless.
And I think the button of install should be the first component, not the last. It is more often used than components.
Where are disbled ones, those without any themes connected to them?
The change is interesting!
Looking at the initial PRs such as:
(but also #29225, #29079)
I appreciate the intention to simplify and create a more user-friendly interface.
I think with the appropriate screenshots and description, it would look quite good!
Merging theme and components makes sense.
Avoiding multiple sidebars seems to be a good idea as well.
My immediate concern is the missing search and filtering, but I’m sure the UI will be refined with improvements later. When you have many components, it’s a must-have feature.
Others feedbacks:
As Jakke said, the install button should be at the top, or at least a shortcut.
Scrolling can be discouraging if you have many components.
You can Set default a component, and of course you are not supposed to do that
When you update a component, I would expect the menu to close once clicked:
Can we find a shorter label? 
I would not mind an option to choose with a grid or list view at the top of the page. E.g:
I’m looking forward to future improvements!
And I really much would like to get search there. It came a bit nauseous when scrolling up and down searching google font component…
I completely agree, this is not a practical approach:
It makes me feel so dizzy.. I actually added some styles to be able to navigate the components page in a straightforward way again 
What I’m trying to do as well.
Out of curiosity, I was trying to create a list or grid button and group it by status. Adding some filtering options at the top would be cool.
The grid view can be interesting for some people, though. For theme, it makes sense, at least.
@osama @ella and @hugh are very much mid-stream on this work, and are discussing some of these same things internally.
By all means, continue to share your feedback here, but do expect this to keep changing in the near future, regardless.
To complement what I said above:
Here is a crude demo (I’m not a designer, just did for fun), I would be pretty happy with something similar:
Another possible view for those who like boxes but with minimal information:
A last feature I wish to see is the ability to enable/disable directly from the list. It will be less straightforward so that a shortcut would be welcome.
Do you feel to share it 
(And yes, I know it would be only temporary fix, but still)
Here you go 
.admin-config.customize.components {
.admin-detail {
padding: 0;
}
.themes-cards-container {
display: flex;
flex-direction: column;
max-width: 500px;
gap: 0;
}
.admin-config-area-card__content {
flex-grow: 0;
margin: 0;
padding: 0;
}
.theme-card {
flex-direction: row;
margin: 0;
padding: 0.75rem;
padding-right: 0;
box-shadow: none;
border: none;
border-top: 1px solid var(--primary-low);
&:first-child {
border-top: none;
}
&__image-wrapper,
&__content {
display: none;
}
&__footer {
gap: 1rem;
}
}
.theme-install-card {
margin-top: 1rem;
}
}
You are my new hero!
—
Aaand, creating new component doesn’t open settings, but it must find from listing and open.
I start feeling more and more convinced that staying on stable is the best choice. After last months site settings drama this is another example of something that was working fine, but was changed and released into production without a feature flag setting, while not being finished or properly tested.
(And for some more constructive feedback on the specific feature - it would at least be very helpful if unused and disabled components can be recognized on the overview screen).
Actually, I just remembered. I legitimately wonder if there is a reason this change is not part of Discourse Design team experimentation topic. That would be the right place among the others, design-experiment.
I agree it feels rushed; without prior information and feature flag setting, I understand it may not deliver the best experience for admins.
There are several different ways that we roll out features, depending on our view of the risk of the given change.
This is a case where it’s pretty low, in my opinion. No one’s workflow is broken and the change is limited to admins, not to every member of a community.
I understand there is some disruption for those who spend a lot of time dealing with themes and components. I’d welcome more stories about how the change has disrupted anyone’s workflow in particular as it’ll help inform our decisions about the design of this part of the application.
I don’t think this is a case where I’d reach for a design experiment or a feature flag though.
I think to make things easier you should also be able to filter components using theme they are add to.
An admin needs to have things make their own lives easier. Experimenting is maybe understandable. But give admins a fallback or a toggle to switch between classic and new coke. Btw iirc new coke didn’t take.
I worked on a client theme and after updating the staging instance was confronted with the new layout. I had to stop and add the styles that I shared above to effectively keep working. The current layout doesn’t allow any overview or give clues about which components are currently in use, which are disabled, etc.. I’d say to develop a theme or a new setup it completely breaks the workflow.
The previous list was actually really good. If I remember correctly it was even improved not so long ago. The only filter it lacked was to filter for components that are used on the current theme (the “Used” filter actually showed all components used on any installed theme). But otherwise it was an interface that didn’t require much improvement, at least not for experienced admins or developers.
Thanks you for the story.
Hearing more about the kinds of problems people are encountering in different scenarios are helpful.
Thanks for sharing this as well.
Well, I would say every single notice in this topic came from trying to do something, that was part of workflow 
I just noticed there is no current filtering even by name.
I’d suggest your team tries to actually use this in a real world scenario… there is so much functionality lacking that’s gone.
