Je voulais indiquer sur la maquette la limite d’imbrication de plusieurs actions “Blocs conditionnels Si… Alors… Sinon…” ? Tu avais écris plus haut : « mettre des limites sur la profondeur (max 1 ou 2 je pense) ». Ça veut dire que 1.A.1 serait le max ? ou 1.A.1.A.1 ? ou 1.A.1.A.1.A.1 ? Moi je voterais pour le cas du milieu
Je voulais préciser aussi sur la maquette la portée d’un déplacement de blocs d’actions. A priori pas de limite technique, et on peut envisager que le déplacement d’un bloc d’actions d’une section “Alors” soit possible au sein de la même section “Alors” (ex: avant 1.A.1.), ou dans la section “Sinon” (ex: après 1.S.2.), et même en dehors de l’action “Blocs conditionnels Si… Alors… Sinon…” (ex: avant 3.) ? Mais pas dans une section « Si… », bien sûr.
Idem pour le déplacement d’une action : Pas de limite technique et on pourra l’emmener n’importe où ? Enfin, sauf dans une section « Si… ».
2/ Je me demande si on ne pourrait pas déplacer les boutons « Nouvelle action + » et « Nouvelle condition + », au lieu d’utiliser la partie droite de ces sections (qui pourrait devenir un bouton collapse), on pourrait peut-être les mettre sous forme d’un bouton centré en bas de la section, qui pourrait être juste une petite icône peut-être ?
3/ Je ne vois pas comment ajouter/retirer des groupes d’actions dans ton design ?
Tu es sûr ? En fait je les ai placé là pour rester cohérent avec ce qui existe aujourd’hui pour ajouter une nouvelle action dans un bloc. Ce que tu suggères serait appliqué dans cette action « Blocs conditionnels… » et également dans les blocs d’action qui existent déjà aujourd’hui (parce que sinon, on rate l’objectif de cohérence) ? Si c’est ça, je me dis que c’est un autre sujet à ouvrir, non ?
Ben comme ce qui existe déjà :
pour retirer un bloc d’action, c’est l’icône ‹ corbeille ›. Elle n’est pas visible dans mes étapes 1-2-3 parce qu’il n’y a qu’un seul bloc, mais on les voit bien à l’étape 4 pour les blocs 1.A.1., 1.A.2., 1.S.1., 1.S.2.
pour ajouter un bloc d’action, c’est automatique dès que tu ajoutes une action dans le dernier bloc vide. Je ne l’ai pas explicité, mais je peux ajouter une Annotation Whimsical pour le préciser.
J’ai remplacé l’étape 4 de mon dernier message, pour ajouter quelques annotations explicatives (mais pas de modif du design, si ce n’est le centrage de texte)
Je crois qu’on converge vers une excellente UI avec les derniers points évoqués, bravo !
J’ajouterai selon moi (mais ça a été peut-être déjà écrit) : bloquer la création à une seule section SI/ALORS/SINON possible par bloc principal (1. ou 2. ou 3. etc., j’espère être assez clair…).
Ah oui, je vois ce dont tu veux parler. Et ce n’est pas que ce serait impossible de gérer en parallèle deux structures Si… Alors… Sinon…, mais c’est juste que graphiquement les deux actions seraient l’une en dessous de l’autre, ce qui ne rendrait pas intuitivement compte de leur exécution en parallèle. J’ai ajouté une annotation dans l’étape 3 de mon précédent message.
Je pense que cest une autre fonctionnalité mais ce serait bien que la conditions prenne la valeur actuel dun appareil sans avoir besoin au préalablement de récupérer cette valeur ?
Je sais pas si je suis clair?
Tu as raison, autant garder le développement simple ici.
Je pensais que le bouton « collapse » allait gêner ces boutons, mais en fait c’est pas dans le même bloc.
Ok effectivement !
Ok merci !
A voir, je suis pas certain que cette limite est si utile que ça…
Autre fonctionnalité !
La suite
@StephaneB Effectivement, je pense qu’on atteint un résultat vraiment satisfaisant en terme d’UI ! Bravo !
Maintenant, il va falloir réfléchir/écrire des spécifications pour définir ce qu’il se passe réellement dans ces conditions.
Typiquement, tu utilises un ensemble de conditions qui actuellement existent déjà, mais ont un fonctionnement très différent : elles stoppent la scène si la condition n’est pas vérifiée.
Il faut réfléchir comment on va travailler avec ces nouvelles conditions: est-ce que c’est les mêmes conditions, mais au lieu de stopper la scène, cela stoppe juste le flow d’exécution « actuel » ?
Quid des scènes existantes ?
Est-ce que c’est carrément des nouvelles conditions ?
Il faut définir et écrire tout le fonctionnement de ce nouveau système
D’ailleurs, je ne suis pas sûr d’avoir vu le design de toutes les conditions.
Merci !! Et merci à tous ceux qui ont fait des retours pour aider à affiner progressivement cette interface.
Alors dans ma tête c’était tout simple et ‹ logique › :
les 5 actions conditionnelles actuelles font effectivement ça : si la condition est remplie, alors la scène continue, sinon la scène s’arrête quand toutes les actions du bloc sont terminées.
les 5 conditions équivalentes qu’on utilisera dans une action « Blocs conditionnels » auront le comportement suivant : si la condition remplie (et que toutes les autres conditions le sont aussi), alors la scène se poursuit dans la section « Alors… », sinon elle se poursuit dans la section « Sinon… ». Puis dans les deux cas la scène se poursuit dans le bloc d’actions suivant.
Est-ce ça que tu attends quand tu dis « spécification » ?
Je ne comprends pas cette question. Une éventuelle migration tu veux dire ? Je ne pense pas qu’il faille envisager ça. Chacun décidera comment il retravaille ses scènes existantes pour utiliser la nouvelle action « Blocs conditionnels », non ?
D’un point de vue UX/UI, il me semble qu’il ne doit y avoir aucune différence entre les 5 actions conditionnelles actuelles. Ainsi, les utiliser dans un cas ou dans l’autre sera compris de la même façon (si ce n’est la différence de comportement décrire juste avant).
Par contre, est-ce que techniquement c’est le même composant, ça c’est plutôt un boulot côté devt, non ?
Je n’ai effectivement pas donné d’exemple utilisant « Condition sur EDF-Tempo » et « Condition sur un événement », mais si je les ajoute ça ne fera que montrer que leur interface est exactement la même, qu’on les utilise comment action conditionnelle ou comment condition dans une action « Blocs conditionnels ».
Voilà, je te laisse me préciser ce que tu as besoin que je spécifie plus précisément.
Il faut faire au cas par cas, mais chaque condition actuellement dans les scènes est quand même étroitement lié au mécanisme de « continuer/interrompre la scène ».
Exemple dans le cas d’une condition sur calendrier :
Je pense qu’il serait utile de créer des maquettes spécifiques pour chaque condition afin de définir la version « SI… ALORS ».
Cela peut sembler évident, mais c’est justement l’objectif d’une spécification : définir ensemble, à l’avance, tout ce qui sera développé, même si cela semble évident.
Une spécification claire permet de commencer le développement sans ambiguïté.
Plus la spécification est détaillée, plus le développement a de chances de réussir !
Si on part du principe qu’il y a un nouveau set de condition dédié au « SI…ALORS », alors oui pas besoin de migration. Mais c’était à définir !
Alors j’ai laissé mes évidences et logiques de côté , et j’ai relu les textes de chacun des 5 actions conditionnelles actuelles. Voilà ce que je propose pour créer les conditions équivalentes dédiées à l’action « Blocs conditionnels (Si… Alors… Sinon…) »:
@pierre-gilles, c’est un détail mais je trouve que le titre de ce sujet n’est plus vraiment pertinent. Que dirais-tu de le changer en 'Scènes : nouvelle action « Blocs conditionnels (Si… alors… Sinon…) » '?
Je trouve que rappeler le fonctionnement du “SI… ALORS” dans chaque condition rend le texte redondant et pas forcément clair.
Comme plusieurs conditions peuvent être présentes, la description actuelle est même plutôt fausse je trouve.
Par exemple, dans la condition sur EDF Tempo, tu écris :
“La scène continuera dans la section ‘Alors…’ si les conditions ci-dessous sur EDF Tempo sont vérifiées.”
Cette formulation peut laisser penser que les conditions sont reliées par un “OU”, alors qu’en réalité, c’est un “ET”.
Si tu veux rappeler le principe du “SI… ALORS”, il vaudrait mieux l’expliquer au début du bloc “SI… ALORS”, plutôt que dans chaque condition.
Dans chaque condition individuelle, il serait plus clair de simplement décrire sa propre validation (ex. : “Cette condition sera valide si…”). Dans certains cas, comme pour EDF Tempo, il me semble même qu’on pourrait simplement supprimer le texte.
J’ai joué un peu ce matin pour tenter une implémentation basée sur ta proposition.
Pour l’instant, j’arrive à ça :
C’est vraiment un premier jet très rapide !
Pour les bouton « + Add action », je trouve que c’était vraiment plus logique en le mettant en dessous, donc j’ai fais le test en modifiant dans ce développement directement.
Pour le « Then… Else… », je trouve qu’encadrer tout avec une card ça rend l’interface trop chargée, donc j’ai juste introduit un décalage.
Pour le caret « > » pour ouvrir/fermer le « Then… Else… », je suis parti sur un caret à gauche au final, je sais pas ce que tu en penses?
Il manque encore plein de choses, mais c’est vraiment chouette je trouve !
Ça rend vraiment bien. Me voilà impatient de pouvoir m’en servir !
Tes choix me semblent pertinents, pas de souci pour moi…
Juste la numérotation des blocs : le « 1.1.Then » est bizarre.
« 1.1 » c’est parce que tu penses autoriser le fait d’avoir plusieurs actions ‹ blocs conditionnels › dans le bloc « 1. », qui seront donc numérotés"1.1" et « 1.2 »,…? Je l’ai dit plus haut, je pense que ça nuira à la lisibilité. Mais bon, à tester…
Et après le then il devrait déjà y avoir un « .1 ». Parce que là c’est sûr qu’on va pouvoir enchaîner plusieurs blocs d’actions, numérotés « Then.1 », « Then.2 »,…
On verra en réel ce qui marche !
, et j’ai relu les textes de chacun des 5 actions conditionnelles actuelles. Voilà ce que je propose pour créer les conditions équivalentes dédiées à l’action « Blocs conditionnels (Si… Alors… Sinon…) »:
