Quería indicar en el boceto el límite de anidamiento de varias acciones “Bloques condicionales Si… Entonces… Sino…”. Más arriba escribiste: « poner límites a la profundidad (máx. 1 o 2 creo) ». ¿Eso significa que 1.A.1 sería el máximo? ¿O 1.A.1.A.1? ¿O 1.A.1.A.1.A.1? Yo votaría por el caso intermedio
También quería precisar en el boceto el alcance de un desplazamiento de bloques de acciones. A priori no hay límite técnico, y se puede considerar que el desplazamiento de un bloque de acciones de una sección “Entonces” sea posible dentro de la misma sección “Entonces” (ej: antes de 1.A.1.), o en la sección “Sino” (ej: después de 1.S.2.), e incluso fuera de la acción “Bloques condicionales Si… Entonces… Sino…” (ej: antes de 3.). Pero no en una sección « Si… », por supuesto.
Igual para el desplazamiento de una acción: ¿No hay límite técnico y se podrá llevar a cualquier parte? Bueno, excepto en una sección « Si… ».
2/ Me pregunto si no podríamos desplazar los botones « Nueva acción + » y « Nueva condición + », en lugar de usar la parte derecha de estas secciones (que podría convertirse en un botón plegable), ¿podríamos ponerlos en forma de un botón centrado al final de la sección, que podría ser solo un pequeño icono?
3/ No veo cómo agregar/eliminar grupos de acciones en tu diseño?
¿Estás seguro? De hecho, los he colocado allí para mantener la coherencia con lo que existe hoy para agregar una nueva acción en un bloque. ¿Lo que sugieres se aplicaría en esta acción « Bloques condicionales… » y también en los bloques de acción que ya existen hoy (porque si no, se pierde el objetivo de coherencia)? Si es así, me parece que es otro tema para abrir, ¿no?
Bueno, como lo que ya existe:
para eliminar un bloque de acción, es el icono ‹ papelera ›. No es visible en mis pasos 1-2-3 porque solo hay un bloque, pero se ven bien en el paso 4 para los bloques 1.A.1., 1.A.2., 1.S.1., 1.S.2.
para agregar un bloque de acción, es automático tan pronto como agregas una acción en el último bloque vacío. No lo he especificado, pero puedo agregar una anotación Whimsical para precisarlo.
He reemplazado el paso 4 de mi último mensaje para añadir algunas anotaciones explicativas (pero sin cambios en el diseño, salvo el centrado del texto)
Creo que estamos convergiendo hacia una excelente interfaz de usuario con los últimos puntos mencionados, ¡bien hecho!
Yo añadiría (pero quizá ya se haya dicho): bloquear la creación de una sola sección SI/ENTONCES/SINO posible por bloque principal (1. o 2. o 3. etc., espero ser lo suficientemente claro…).
Ah sí, ya veo de qué hablas. Y no es que sería imposible gestionar en paralelo dos estructuras Si… Entonces… Si no…, pero es que gráficamente las dos acciones estarían una debajo de la otra, lo que no reflejaría intuitivamente su ejecución en paralelo. He añadido una anotación en el paso 3 de mi mensaje anterior.
Creo que es otra funcionalidad, pero sería genial que la condición tomara el valor actual de un dispositivo sin necesidad de recuperar previamente ese valor.
¿No sé si me explico?
Tienes razón, mejor mantener el desarrollo simple aquí.
Pensé que el botón « collapse » iba a interferir con estos botones, pero en realidad no están en el mismo bloque.
¡Vale, efectivamente!
¡Vale, gracias!
A ver, no estoy seguro de que esta limitación sea tan útil…
¡Otra funcionalidad!
La continuación
@StephaneB Efectivamente, creo que estamos llegando a un resultado realmente satisfactorio en cuanto a la interfaz de usuario! ¡Bravo!
Ahora, habrá que reflexionar/escribir especificaciones para definir lo que realmente ocurre en estas condiciones.
Típicamente, utilizas un conjunto de condiciones que ya existen, pero tienen un funcionamiento muy diferente: detienen la escena si la condición no se verifica.
Hay que reflexionar cómo vamos a trabajar con estas nuevas condiciones: ¿son las mismas condiciones, pero en lugar de detener la escena, solo detienen el flujo de ejecución « actual »?
¿Qué pasa con las escenas existentes?
¿Son condiciones completamente nuevas?
Hay que definir y escribir todo el funcionamiento de este nuevo sistema:D
De todos modos, no estoy seguro de haber visto el diseño de todas las condiciones.
¡Gracias! Y gracias a todos los que han dado su opinión para ayudar a afinar progresivamente esta interfaz.
Para mí era algo simple y ‹ lógico ›:
Las 5 acciones condicionales actuales hacen exactamente eso: si la condición se cumple, la escena continúa; de lo contrario, la escena se detiene cuando todas las acciones del bloque se completan.
Las 5 condiciones equivalentes que usaremos en una acción « Bloques condicionales » tendrán el siguiente comportamiento: si la condición se cumple (y todas las demás también), entonces la escena continúa en la sección « Entonces… », de lo contrario, continúa en la sección « De lo contrario… ». Luego, en ambos casos, la escena continúa en el bloque de acciones siguiente.
¿Es eso lo que esperas cuando dices « especificación »?
No entiendo esta pregunta. ¿Te refieres a una posible migración? No creo que haya que considerar eso. Cada uno decidirá cómo rehacer sus escenas existentes para usar la nueva acción « Bloques condicionales », ¿no?
Desde el punto de vista de la experiencia de usuario/interfaz de usuario, me parece que no debería haber ninguna diferencia entre las 5 acciones condicionales actuales. Así, usarlas en un caso u otro se entenderá de la misma manera (a menos que la diferencia de comportamiento descrita justo antes).
Por otro lado, ¿técnicamente es el mismo componente? Eso es más un trabajo del lado del desarrollo, ¿no?
De hecho, no he dado un ejemplo utilizando « Condición sobre EDF-Tempo » y « Condición sobre un evento », pero si los añado solo mostrará que su interfaz es exactamente la misma, ya sea que las usemos como acción condicional o como condición en una acción « Bloques condicionales ».
Eso es todo, te dejo que me indiques qué necesitas que especifique con más precisión.
Hay que hacerlo caso por caso, pero cada condición actualmente en las escenas está estrechamente vinculada al mecanismo de « continuar/interrumpir la escena ».
Ejemplo en el caso de una condición en el calendario:
Creo que sería útil crear maquetas específicas para cada condición a fin de definir la versión « SI… ENTONCES ».
Puede parecer evidente, pero es precisamente el objetivo de una especificación: definir juntos, de antemano, todo lo que se desarrollará, incluso si parece evidente.
Una especificación clara permite comenzar el desarrollo sin ambigüedades.
Cuanto más detallada sea la especificación, más posibilidades tendrá el desarrollo de tener éxito.
Si partimos del principio de que hay un nuevo conjunto de condiciones dedicado al « SI…ENTONCES », entonces no, no hay necesidad de migración. Pero eso era para definir.
Así que dejé mis evidencias y lógica a un lado , y releí los textos de cada una de las 5 acciones condicionales actuales. Esto es lo que propongo para crear las condiciones equivalentes dedicadas a la acción « Bloques condicionales (Si… Entonces… Si no…) »:
@pierre-gilles, es un detalle, pero creo que el título de este tema ya no es muy relevante. ¿Qué te parecería cambiarlo a ‹ Escenas: nueva acción « Bloques condicionales (Si… entonces… Si no…) » ›?
Creo que recordar el funcionamiento del “SI… ENTONCES” en cada condición hace que el texto sea redundante y no necesariamente claro.
Como pueden haber varias condiciones, la descripción actual incluso me parece falsa.
Por ejemplo, en la condición sobre EDF Tempo, escribes:
“La escena continuará en la sección ‘Entonces…’ si se verifican las condiciones a continuación sobre EDF Tempo.”
Esta formulación puede dar a entender que las condiciones están conectadas por un “O”, cuando en realidad es un “Y”.
Si quieres recordar el principio del “SI… ENTONCES”, sería mejor explicarlo al principio del bloque “SI… ENTONCES”, en lugar de en cada condición.
En cada condición individual, sería más claro simplemente describir su propia validación (ej.: “Esta condición será válida si…”). En algunos casos, como el de EDF Tempo, incluso me parece que podríamos simplemente eliminar el texto.
Esta mañana he jugado un poco para intentar una implementación basada en tu propuesta.
Por ahora, he llegado a esto:
¡Es realmente un primer borrador muy rápido!
Para los botones « + Agregar acción », creo que era mucho más lógico ponerlos abajo, así que hice la prueba modificando directamente en este desarrollo.
Para el « Then… Else… », creo que enmarcarlo todo con una tarjeta hace que la interfaz esté demasiado cargada, así que solo introduje un desplazamiento.
Para la flecha « > » para abrir/cerrar el « Then… Else… », al final me decidí por una flecha a la izquierda, no sé qué te parece.
Aún faltan muchas cosas, pero ¡realmente me parece genial!
¡Queda realmente bien! ¡Ahora estoy impaciente por poder usarlo!
Tus elecciones me parecen pertinentes, no hay problema para mí…
Solo la numeración de los bloques: el « 1.1.Then » es raro.
« 1.1 » es porque piensas permitir tener varias acciones de ‹ bloques condicionales › en el bloque « 1. », que por lo tanto estarán numerados « 1.1 » y « 1.2 »,…? Lo dije más arriba, creo que perjudicará la legibilidad. Pero bueno, habrá que probarlo…
Y después del then ya debería haber un « .1 ». Porque ahora sí que podremos encadenar varios bloques de acciones, numerados « Then.1 », « Then.2 »,…
¡Veremos en la práctica lo que funciona!
, y releí los textos de cada una de las 5 acciones condicionales actuales. Esto es lo que propongo para crear las condiciones equivalentes dedicadas a la acción « Bloques condicionales (Si… Entonces… Si no…) »:
