Le problème que j’ai avec la façon de faire de zwave c’est que tu peux pas spécifier le nom de chaque variable (température, humidité, …). Du coup est-ce que l’on modifie juste le nom du capteur de manière général et ensuite on met par exemple Capteur 1 Température, Capteur 1 Humidité. (Où le nom du capteur est donc Capteur 1).
Qu’en penses tu / pensez vous ?
C’est pour que tous les modules soit sur la même longueur d’onde. Car effectivement si on laisse moins de possibilité à l’utilisateur de personnalisation du nom de chaque feature, alors on peut faire un truc plus sexy
Je trouve que forcer l’utilisateur à nommer chaque deviceFeature un par un, c’est hyper lourd… Et est-ce que c’est utile? Je pense que non.
C’est à nous de designer une UI où il est facile de discerner quel capteur est quoi/et où.
Je serais intéressé de savoir plus d’exemples d’autres plateformes, pour comprendre quelles techniques d’UI ont été utilisées pour permettre à un utilisateur de comprendre son installation, même si celle-ci est très riche.
Je pense que c’est un problème à cause des utilisateurs de Gladys actuel … Des techniques …
En tant que utilisateur standard je préfère pas m’embêter. Je peux partir sur le principe de faire comme zwave et permettre moins de modification. On peut se dire que l’utilisateur avancé ouvre la BDD et change la valeur directement à ses risques et périls.
Autre possibilité est tout simplement d’avoir un mode avancé (à mettre en place du côté des settings et ensuite de laisser apparaitre dans les modules d’autres options). C’est une possibilité qui peut être rajouté par la suite!
Je sais que cette idée est pas génial mais ça peut répondre à la problématique.
En tout cas pour Xioami je pars sur un truc plus simple et beau qui parle à tous. On verra plus tard ce sont des pistes de réfléxions.
Je ne pense pas! Je pense que les utilisateurs, technique ou non, veulent juste une UI claire qui fait le boulot.
Dans Gladys 3, la seule façon d’avoir une UI assez clair c’était de nommer chaque feature individuellement, c’était l’UI qui voulait ça.
Je veux revoir l’UI de Gladys 4 pour que ce ne soit pas nécessaire. Je pense d’ailleurs que le nom du deviceFeature peut être obsolète si on fait bien notre UI…
De mon point de vue, device et device-feature ne doivent pas être traitées à égal:
Le nom du device, même si défini par défaut par le système doit être modifiable. Dans ton exemple, @pierre-gilles, garage door est sûrement défini par l’utilisateur. Dans un cas pratique où on aurait 2 portes de garage, le système pourrait les appeler garage-door-1 et garage-door-2 et l’utilisateur de les modifier en garage-front-door et garage-back-door parce que bon, c’est plus facile pour savoir kikoikece.
Pour les device-features je ne vois pas en quoi l’utilisateur devrait renommer quoi que ce soit. Ouvert/Fermé/Allumé/Éteint /%batterie/couleur… c’est intimement lié au type de device et aux fonctionnalités dont il dispose. Ces fonctionnalités sont hard codées et liées à des constantes dans le système.
Une feature = « une action » = une appellation / un état.
Si on prend l’exemple d’un capteur de température aka “temperature-sensor”.
Il peut implémenter différentes features (fonction de la marque du modèle…) ça n’en reste pas moins un capteur de température.
Maintenant en fonction de ces features, l’UI fera apparaître :
24°C
84% humidity (ou pas)
1020 hPa (ou pas)
Hormis des réglages globaux d’environnement sur le système métrique (°C /F etc), je ne vois pas d’intérêt de personnaliser la sortie de ces features. C’est normalisé, y’a un nom, une icône, des boutons (et des actions liées).
Et pourtant, je suis un user qui aime personnaliser
Vu comme ça c’est chouette, effectivement. Mais du coup c’est une vue de features, pas de devices.
Tu pourrais avoir les deux mesures Temp et Humidité sur la même ligne aussi, non ?
Si j’prends l’exemple d’une lampe, ça a moins de sens de faire 1 ligne pour on/off, une autre pour color, et une autre dimmer.
D’ou mon ressenti qu’une ligne par device c’est « mieux ».
Et d’un côté pur tech, tu passes ton device ds une func displayDevice qui est capable de générer la ligne en question en se basant sur les différentes features du dit device.
Où humidity, temperature sont juste des variables qui ne sont pas en lien avec la base de données juste le fait que la feature affiche la temperature
Du coup refaire un petit peu la vue dashboard / device pour avoir une vrai vue en fonction des devices et non des features.
J’ai pensé à cette vue qui du coup peut alier les deux pas forcément faire sur une ligne (ca peut être dégueulasse) mais avoir la distinction des devices.
J’comprends pas exactement ce que tu veux dire… Si tu parles des « labels » effectivement, ce ne serait pas en base. Plutôt dans le fichier de trad à un index correspondant au device-feature.
En ce qui concerne 1 ou pls lignes, il faut en discuter, faire des essais. Peut-être que c’est mieux pour un device, et moins adapté pour un autre. Mais le regroupement par device me semble inévitable pour s’y retrouver.
Peut-être une règle du genre « 1 ligne par sensor, mais toutes les actions sur la même ligne ».
Bref… à challenger comme disent les consultants de mon ancienne boîte
Je bosse sur une vue un peu différente de ce que l’on a actuellement. J’aime pas encore trop le rendu il y a quelque chose qui ne va pas mais sinon l’idée est d’avoir une seule fois le nom du capteur et d’avoir toutes ses features (pas besoin du nom de la feature).
Je trouve du coup plus facile tu vois rapidement ce que tu cherches (en l’occurence par exemple la température alors que quand tu as Xiaomi-1-temperature-sensor …
Je dirais pas que c’est “ze” affichage, mais j’aime beaucoup l’idée de “regroupement”. Je trouve ça plus facile à comprendre.
En revanche, si j’ai 10 devices avec 1 seule feature, je ne voudrais pas voir un ecran trop chargé.
Aux autres, partagez vos avis, cela les aidera pour faire des essais.
Oui 10 devices une feature pas forcément très pratique !! Il faut s’adapter en fontion du nombre de feature peu être au dela de deux on passe comme ca autrement on reste ur une ligne
La capture de @damalgos me plaît bien
Effectivement en jouant davantage sur les icônes / images / couleurs / formes, on peut s’affranchir de texte et ce sera plus visuel ainsi que plus esthétique
