Euh… êtes-vous sûr de cette disposition ?
Cela rend la recherche du bon composant vraiment difficile. Et ça a l’air… vraiment agité.
Et je pense que le bouton d’installation devrait être le premier composant, pas le dernier. Il est plus souvent utilisé que les composants.
Où sont ceux désactivés, ceux sans aucun thème connecté à eux ?
Le changement est intéressant !
En regardant les PR initiaux tels que :
(mais aussi #29225, #29079)
J’apprécie l’intention de simplifier et de créer une interface plus conviviale.
Je pense qu’avec des captures d’écran et une description appropriées, cela aurait fière allure !
La fusion des thèmes et des composants est logique.
Éviter les barres latérales multiples semble également être une bonne idée.
Ma préoccupation immédiate est l’absence de recherche et de filtrage, mais je suis sûr que l’interface utilisateur sera peaufinée avec des améliorations plus tard. Lorsque vous avez de nombreux composants, c’est une fonctionnalité indispensable.
Autres commentaires :
Comme l’a dit Jakke, le bouton d’installation devrait être en haut, ou du moins un raccourci.
Le défilement peut être décourageant si vous avez de nombreux composants.
Vous pouvez définir un composant comme Défaut, et bien sûr, vous ne devriez pas le faire
Lorsque vous mettez à jour un composant, je m’attendrais à ce que le menu se ferme une fois cliqué :
Pouvons-nous trouver une étiquette plus courte ? 
Je ne serais pas contre une option pour choisir une vue en grille ou en liste en haut de la page. Par exemple :
J’attends avec impatience les futures améliorations !
Et j’aimerais vraiment beaucoup y trouver une recherche. C’est devenu un peu nauséeux de faire défiler vers le haut et vers le bas en cherchant le composant de police Google…
Je suis tout à fait d’accord, ce n’est pas une approche pratique :
Cela me donne le tournis… J’ai en fait ajouté quelques styles pour pouvoir à nouveau naviguer dans la page des composants de manière simple 
Ce que j’essaie de faire aussi.
Par curiosité, j’essayais de créer un bouton de liste ou de grille et de le regrouper par statut. Ajouter des options de filtrage en haut serait bien.
La vue en grille peut être intéressante pour certaines personnes, cependant. Pour le thème, cela a du sens, du moins.
@osama @ella et @hugh sont en plein milieu de ce travail, et discutent de certaines de ces mêmes choses en interne.
N’hésitez pas à continuer de partager vos commentaires ici, mais attendez-vous à ce que cela continue de changer dans un avenir proche, peu importe.
Pour compléter ce que j’ai dit ci-dessus :
Voici une démo rudimentaire (je ne suis pas designer, juste fait pour le plaisir), je serais assez content avec quelque chose de similaire :
Une autre vue possible pour ceux qui aiment les boîtes mais avec un minimum d’informations :
Une dernière fonctionnalité que j’aimerais voir est la possibilité d’activer/désactiver directement depuis la liste. Ce sera moins direct, donc un raccourci serait le bienvenu.
Tu te sens de partager ça 
(Et oui, je sais que ce ne serait qu’une solution temporaire, mais quand même)
Voici 
.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;
}
}
Tu es mon nouveau héros !
—
Et, créer un nouveau composant n’ouvre pas les paramètres, mais il doit le trouver dans la liste et l’ouvrir.
Je commence à être de plus en plus convaincu que rester sur la version stable est le meilleur choix. Après le drame des paramètres du site le mois dernier, voici un autre exemple de quelque chose qui fonctionnait bien, mais qui a été modifié et déployé en production sans réglage de drapeau de fonctionnalité, tout en n’étant pas terminé ou correctement testé.
(Et pour des commentaires plus constructifs sur la fonctionnalité spécifique - il serait au moins très utile de pouvoir reconnaître les composants inutilisés et désactivés sur l’écran d’aperçu).
En fait, je me souviens juste. Je me demande légitimement s’il y a une raison pour que ce changement ne fasse pas partie de Discourse Design team experimentation topic. Ce serait le bon endroit entre autres, design-experiment.
Je suis d’accord que cela semble précipité ; sans information préalable et sans paramètre de fonctionnalité, je comprends que cela puisse ne pas offrir la meilleure expérience aux administrateurs.
Il existe plusieurs façons différentes de déployer des fonctionnalités, en fonction de notre évaluation du risque du changement donné.
C’est un cas où le risque est assez faible, à mon avis. Le flux de travail de personne n’est perturbé et le changement est limité aux administrateurs, pas à chaque membre d’une communauté.
Je comprends qu’il y ait une certaine perturbation pour ceux qui passent beaucoup de temps à gérer les thèmes et les composants. J’apprécierais d’avoir plus de témoignages sur la façon dont le changement a perturbé le flux de travail de quiconque en particulier, car cela nous aidera à prendre des décisions concernant la conception de cette partie de l’application.
Je ne pense pas que ce soit un cas où je recourrais à une expérience de conception ou à un indicateur de fonctionnalité.
Je pense que pour faciliter les choses, vous devriez également pouvoir filtrer les composants par le thème auquel ils sont ajoutés.
Un administrateur a besoin que les choses lui facilitent la vie. L’expérimentation est peut-être compréhensible. Mais donnez aux administrateurs une solution de repli ou un interrupteur pour passer de l’ancienne à la nouvelle version. Au fait, si je me souviens bien, la nouvelle version n’a pas pris.
J’ai travaillé sur un thème client et, après avoir mis à jour l’instance de staging, j’ai été confronté à la nouvelle disposition. J’ai dû m’arrêter et ajouter les styles que j’ai partagés ci-dessus pour pouvoir continuer à travailler efficacement. La disposition actuelle ne permet aucun aperçu ni ne donne d’indices sur les composants actuellement utilisés, désactivés, etc. Je dirais que développer un thème ou une nouvelle configuration casse complètement le flux de travail.
La liste précédente était en fait très bonne. Si je me souviens bien, elle avait même été améliorée il n’y a pas si longtemps. Le seul filtre qui lui manquait était de filtrer les composants utilisés dans le thème actuel (le filtre “Utilisé” affichait en fait tous les composants utilisés dans n’importe quel thème installé). Mais sinon, c’était une interface qui ne nécessitait pas beaucoup d’améliorations, du moins pas pour les administrateurs ou les développeurs expérimentés.
Merci pour votre témoignage.
Entendre davantage parler des types de problèmes que les gens rencontrent dans différents scénarios est utile.
Merci de partager cela également.
Eh bien, je dirais que chaque remarque dans ce sujet est née d’une tentative de faire quelque chose, qui faisait partie du flux de travail 
Je viens de remarquer qu’il n’y a actuellement aucun filtrage, même par nom.
Je suggérerais à votre équipe d’essayer d’utiliser ceci dans un scénario réel… il y a tellement de fonctionnalités qui manquent ont disparu.
