Serait-il judicieux d’avoir dans la doc, accessible depuis l’integration MQTT, un descriptif et / ou une image de ce que chaque fonctionnalité va donner niveau UI sur le dashboard ?
Car si je cherche à afficher un slider, il me faut pour le moment deviner que ça s’appelle un variateur, ou bien que c’est dans les lumières, etc…
Si j’avais un visuel du rendu final, ça aiderait au choix de ma fonctionnalité.
C’est une bonne idée ! Là dessus, je pense à 2 choses:
Autre option: Repenser l’écran MQTT pour afficher cette « doc » directement dans l’intégration.
Je pense que pour tout ça vous n’avez pas forcément besoin de mon aide, c’est principalement du contenu à écrire 
@qleg Toi qui fait souvent des PRs pour les traductions, limite si tu veux travailler en concert avec @guim31 sur le sujet !
Moi je veux bien me pencher sur ce que vous voulez, mais je ne sais pas utiliser Github (à part pour écrire des Issues) et je ne sais pas utiliser un environnement de développement.
Pour moi, il serait VRAIMENT une meilleure option d’intégrer cette doc dans l’intégration MQTT. Le lambda (dont je fais partie) ne clique que très rarement sur un lien Documentation dans une page web.
Tu verrais ça comment ?
Là comme ça je sèche un peu, mais je veux bien prendre du temps pour y songer et proposer ! 
Alors j’ai fait très vite fait ce machin, j’avoue que mes compétences m’obligent à du bricolage ^^
L’idée est :
Sur la page de création d’un device MQTT, il n’y aurait plus le champ de recherche de fonctionnalité, mais seulement le bouton :
Lorsque l’on clique sur le bouton, s’affiche alors sous le bouton / dans un modal / autre à définir, un encart qui serait surmonté du fameux champ de recherche, ainsi que le « catalogue » des features, qui pourrait être présenté comme ça :
J’ai pas été hyper exhaustif j’avoue ^^ mais l’idée c’est de voir le nom « générique » de la feature, son rendu sur le dashboard, mais aussi les mots-clés auxquels il est rattaché (à voir si c’est super pertinent de les afficher ou non).
Ainsi quelqu’un qui va commencer à taper temp, va créer un filtre de toutes les features contenant cette chaine, comme dans le fonctionnement actuel, mais verra très rapidement ce qu’il recherche : un capteur de température ? Un variateur ? Un variateur de température de couleur ? un détecteur de tempête ?! 
Voilà pour l’idée globale. A vos avis !
Jaime bien l’idée ! De memoire PG disait :
Les modals je pense que cest a proscrire d’un point de vue utilisateur car pas pratiques.
A voir comment intégrer ce composant catalogue
c’est vrai que ca a de la gueule !!!
Alors ce que je trouverai intéressant, à voir si ça rentre dans les guidelines de Gladys niveau UI, ce serait un système de collapse, pour que ce catalogue s’ouvre en dessous du bouton que l’on vient de cliquer. Je trouve que ça guiderait bien l’utilisateur dans sa démarche de création de device.
C’est pas mal ! J’aime bien l’idée, après comment ça rendrait la partie « search/sélection » de la fonctionnalité ?
Parce que cette partie aura déjà les fonctionnalité déjà créé. En plus, niveau fonctionnalité possibles dans Gladys, on parle de dizaines de possibilités, donc ça risque de faire énorme cette partie
Je suis pas certain de comprendre ta question.
En fait dans ma tête c’est un div qui s’afficherait sous le bouton une fois qu’on a cliqué dessus, disons arbitrairement d’une hauteur de 300px, qui serait donc scrollable (et même si je me plante complètement je dirai en « lazy loading » ? c’est comme ça qu’ont dit les trucs qui se chargent au fur et à mesure du scroll?).
En gros j’imagine que la hauteur de ce cadre devrait permettre d’afficher au moins 1 ligne et demi de fonctionnalités, afin que les gens comprennent qu 'ils peuvent faire défiler.
Ça permet surtout de pas avoir 85 tuiles qui vont faire déborder la page à l’infini.
Je ne vois pas de moyen plus efficace d’avoir tout d’un coup d’oeil et de garder le côté searchable pour aller directement là où l’on veut.
