Au lieu de SOURCE et DESTINATION, serait-il possible de mettre ANCIEN et NOUVEAU.
Comme l’indique la doc (et le tuto à l’origine), il est conseillé de mettre _old sur son ancien équipement. Autant mettre ces termes ANCIEN et NOUVEAU dans l’interface pour que les choses soient plus claire.
La notion de source et destination quand on veut remplacer un équipement par un autre n’est pas aussi limpide.
Il ne s’agit, par exemple pour le passage d’un équipement du plugin Openzwave vers Zwave JS, pas d’un nouvel équipement : mais bien du même équipement qui migre.
- En aucun cas il y a un ancien ou un nouveau : c’est bien le même.
Donc l’action de transfert de l’équipement du plugin source vers le plugin cible prend alors tout son sens.
Comme dit par @lperenna, c’est logique et le standard.
Faut-il nécessairement penser comme un informaticien (que je suis pourtant) pour utiliser Jeedom ?
Ma suggestion, me semble-t-il, permettrait de s’adapter à une logique utilisateur plutôt qu’à une stricte logique technique, ce qui améliorerait grandement l’ergonomie et l’accessibilité de Jeedom pour tous.
Encore une fois, quand on veut remplacer un équipement par un autre sans avoir à tout changer manuellement, ce qui est l’objet même de cette fonction, la notion de source et destination me semble source de confusion.
Je vous invite à l’expliquer autour de vous à des non informaticiens pour voir. De mon point de vue, l’ergonomie ne peut se résumer à « c’est logique pour un informaticien ».
Relisez ma réponse précédent la votre. Je vous assure que tout le monde comprend.
Il n’y a pas d’ancien ou de nouveau dans cette histoire.
C’est encore plus étonnant si vous êtes dans l’informatique.
J’utilise pourtant bien cette fonction pour remplacer un équipement par un autre.
J’ai tout un tas de virtuels et scénarios et quand je « remplace » un équipement, c’est bien pour que les commandes de l’ancien équipement (par exemple prise zwave) soient remplacées par celle du nouvel équipement (par exemple prise zigbee), sans avoir à modifier tous les virtuels et les scénarios.
J’ai eu la chance de travailler avec des ergonomes et c’est toujours intéressant de se mettre dans la posture d’un utilisateur lambda, non technicien. Et de penser le vocabulaire en fonction du cas d’usage.
Vous pensez la fonction de manière technique : je vais recopier les commandes depuis une source, vers une destination.
Mais je cite la doc " un nouvel outil Remplacer qui, assurera la recopie de l’ensemble des commandes, informations, paramètres avancés et historique de cet équipement vers un nouvel équipement.
Oui vous avez bien lu, « nouvel » et ce n’est pas moi qui l’écrit.
Je continue dans la doc « En effet, si l’ancien équipement est supprimé, la référence à son numéro d’ID original sera définitivement effacée. Il faudra alors recréer toutes les commandes et les réintégrer dans l’ensemble des designs, widgets, etc… pour le nouveau module, et ce même si celui-ci est strictement de même type que l’original, voire le même mais avec un numéro d’ID différent. »
je propose donc juste que l’IHM soit cohérente avec le cas d’usage et la doc.
C’est que, pour Jeedom, un équipement est un alias d’un périphérique avec l’ensemble de ces commandes (sachant qu’un périphérique n’est pas obligatoire non plus).
Moi, je citais l’exemple de l’usage de la fonction Remplacer pour permuter un équipement d’un plugin à un autre.
Bon, sinon, je viens de poser la question autour de moi, source / cible : tout le monde l’a compris.
Vu sous un autre angle, comme c’est la saison, un sapin de Noël sera bien transféré d’un emplacement source (pépinière) vers un emplacement cible (nos maison).
Si je remplace par ancien et nouveau : ce perd tout son sens.
Bonjour
Je confirme moi aussi avoir toujours eu un doute sur cet outil. Donc au final je ne l’utilise pas. Je pense que Source-Destination n’est pas parlant.
Bonjour,
Plus exactement c’est parlant pour les informaticiens.
La problématique est bien, Jeedom est-il fait pour les informaticiens seulement et les personnes capables de le devenir ou bien pour tous les gens capables de réfléchir 5mn mais sans culture informatique.
A voir les possibilités immenses des Scénarios dans Jeedom, je pencherais pour la 2eme proposition.
Je pense également que les informaticiens doivent avoir les capacités pour se mettre au niveau des gens qui, par le biais de la domotique sont confrontés pour la première fois à la programmation informatique.
Y a pas de débat informaticien/dev vs les autres non plus; arrêtez les clivages!
faut juste accepter que certains mots/définitions parleront à certains et pas à d’autres et ca sera toujours pareil pour tout: une couleur, la place d’un bouton, la police utilisé, le logo etc
le tout est de à un moment faire un choix qui convient à un plus grand nombre mais jamais il ne sera possible de contenter tout le monde
et dites vous bien que personne ici n’a tord, ni raison… ce ne sont que des avis personnel, il n’y a pas grand chose d’objectif dans tout ça…
Un petit sondage pour trancher, s’il y a plus de 100 votes je m’engage à faire le PR pour modifier en conséquence si besoin et on arrête ce débat stérile ici.
Je préfère les termes ancien/nouveau
Je préfère les termes source/destination
Je préfère qu’on travaille/améliore autre chose qui aura plus de valeur à mes yeux
Je m’en fiche, je ne sais même pas pourquoi je répond