@pierre-gilles, He revisado este tema después de este intercambio:
Y bien, me parece que tu propuesta del 6 de noviembre de 2023 fue recibida bastante favorablemente, excepto por aquellos que estaban preocupados de que esto no redujera el número de escenas. Pero eso fue antes de la aparición de las etiquetas, por lo que me digo que ya no sería un problema.
En cualquier caso, para un tema que es el Top1 en número de votos, merece la pena reflexionar sobre ello
Preguntabas cómo lo hacía Apple en sus atajos. Lo ilustro con la pantalla de abajo. Y me parece satisfactorio si hay pocas acciones en el camino ‹ entonces › y el camino ‹ sino ›. Pero si se vuelve largo, en mi opinión no es legible y lo que propones (enviando el ‹ sino › a otra escena) es preferible.
Y en Zapier, es la pantalla de abajo. Bastante simpático, pero no fácilmente adaptable a la presentación actual de las escenas en Gladys, por lo que significaría demasiadas cosas que rehacer para lograrlo. Tu propuesta es más pragmática
Creo que es posible llegar a un compromiso sobre esta función si/entonces/sino con una sola acción a realizar (y pasamos a la siguiente) o bien, si hay varias acciones encadenadas, se lanza una escena (ya sea en el entonces o en el sino).
Pero si se lanza una escena, ¿hay que detenerla o esperar a que termine la ejecución de la escena?
Yo optaría por un retorno (actualmente sé que no es así porque me he equivocado).
Y me iría un poco más allá en la interfaz de usuario, a saber, que podríamos « cambiar » a la escena para editarla (guardando la actual con un pequeño mensaje de alerta si es necesario guardar o no), y si editamos esta escena sola, sería necesario saber que tiene una escena padre (o varias, un poco como una subrutina).
Me estoy emocionando un poco…
Me olvidaba de decir que mantenemos el continuar si, para mí son funciones adicionales.
Reconozco que mi propuesta era un poco una solución de contorno, y con el tiempo, estoy de acuerdo con los comentarios: al final no cambia mucho el problema
El verdadero tema aquí no es tanto tener un “Continuar solo si” con un “sino”, sino más bien introducir escenas con varios flujos de ejecución posibles, en lugar de un solo escenario lineal como es el caso actualmente.
He probado la propuesta de Apple con Shortcuts, ¡y funciona bastante bien! En todo caso, funciona bien en móvil, lo que me parece ser el criterio número 1.
Zapier también es interesante, pero me proyecto menos en su uso móvil. ¡Estoy curioso de ver cómo queda en móvil!
Zapier en móvil no tiene una app específica (al menos en iOS), por lo que es una web app y el diseño no se modifica. Es como con Node-RED, solo ves una pequeña parte de tu algoritmo completo… Y Zapier muestra una advertencia « Zapier funciona mejor en una pantalla grande »
@StephaneB ¿Te apetecería liderar este tema y hacernos una propuesta en Whimsical inspirada en lo que hace Apple?
La idea sería tener un bloque « SI » que contuviera dos bloques « ENTONCES » y « SI NO » que serían ellos mismos grupos de acciones clásicas de Gladys.
Para mantener las escenas limpias, podríamos poner límites en la profundidad (máximo 1 o 2, creo), pero al menos ¡será mucho mejor que ahora!
Es cierto que es lo que hace Zapier y abre completamente las posibilidades: no es un « si entonces sino », es un cruce donde cada camino posible tiene su propia condición para acceder a él. Lo que hace que, imagino, la escena puede empezar a seguir varios caminos en paralelo, si varias condiciones se cumplen. Pero no estoy seguro de que haya que llegar tan lejos.
Estoy de acuerdo en que funciona, pero creo que habría que encontrar una forma clara de identificar que estamos en los pasos de un « entonces » o de un « sino ». La simple y ligera indentación de los bloques en Shortcuts no es lo mejor…
Puedo intentarlo, sí, pero necesito familiarizarme con Whimsical. ¿Es la herramienta obligatoria para ti (porque al final te permite hacer una especie de conversión automática a código para el front end de Gladys)? ¿O si uso otra cosa para hacer un render visual también te sirve?
Las zonas « Entonces » y « Si no » serían exactamente las mismas zonas que el « 1. » de arriba, es un grupo de acción que se puede rellenar con lo que queramos.
dices « Las zonas Entonces y Sino serían exactamente las mismas que la zona 1 »: ¿eso significa que solo se pueden poner acciones que se realizan en paralelo (sería un único bloque)? ¿O contemplas que podamos definir bloques que se encadenan uno tras otro?
con la condición mostrada así, entiendo que es un bloque equivalente a ‹ continuar solo si ›, por lo que podremos añadir ‹ O › si queremos. Pero veo menos cómo encadenar varios ‹ bloques de condiciones › para que se traten como ‹ Y ›.
Creo que en los dos casos debería ser posible: encadenar bloques en un Entonces y en un Sino, y definir condiciones con la lógica ‹ Y ›. ¿Estás de acuerdo?
Si es así, ¿sigues con el boceto o quieres que yo me haga cargo? ¿Y es posible en whimsical que me compartas lo que has empezado?
Es efectivamente una posibilidad. Pero voy a intentar hacer un modelo donde el secuencial sea posible, será mejor. Y si hace que la interfaz sea ilegible, quizá tengamos que volver a lo que propones
Entonces, aquí tienes 3 maquetas para proponer una nueva acción « Si… Entonces… Si no… »:
Maqueta 1: se elige la acción
Maqueta 2: la acción se muestra, con las diferentes zonas a configurar: Si / Entonces / Si no
Maqueta 3: un ejemplo de escena para ilustrar. Si la calefacción está apagada y hace fresco en el salón o en el comedor, enciendo el radiador y lo confirmo con un mensaje 5 minutos después. Y si no (si el radiador ya está encendido, o si hace suficiente calor en una de las dos habitaciones), la luz del salón se enciende y se apaga después de 15 minutos (no me preguntéis por qué, este ejemplo es ridículo, lo sé…). Finalmente, en los dos casos, se envía un mensaje.
Las condiciones en la parte « Si » son muy similares a la acción « Continuar solo si ». De hecho, solo he modificado el título. Y en esta sección « Si », solo se podrían añadir condiciones como esa, no otras acciones, por supuesto. De ahí que el botón sea « Añadir una condición » y no « Nueva acción ».
Los dos bloques « Entonces » y « Si no » permitirían encadenar bloques secuenciales. La numeración de los bloques con la ‹ A › para « Entonces » y la ‹ S › para « Si no » debería ayudar a orientarse…
Y el otro punto se refiere a la A y la S en la numeración.
A primera vista, puedo confundir la S con el 5 (sí, mi vista se debilita cada año ).
Para la lengua de Molière, A=Entonces / S=De lo contrario, pero para otros idiomas, ¿la letra cambia de manera automática?
Si es en inglés, tenemos T=Then / E=Else, en alemán tendríamos D=Dann / S=Sonst pero quizás O=Oder (no soy bilingüe en alemán).
No estoy seguro de que sea lo ideal, pero es mi opinión muy personal.
Y seguramente que el O (o) y el I (i) que podrían confundirse con 0 y 1.
Pasando a minúsculas podría funcionar, o bien un icono específico… no tengo la idea del siglo en este momento…
Después de una pequeña charla con Perplexity, algunas ideas:
1. (bloque) Si/Entonces/De lo contrario
SI condición
Entonces
1.A01.1 acción 1
1.A01.2 acción 2
De lo contrario
1.B01.1 acción 3
1.B01.2 acción 4
1. (bloque) Si/Entonces/De lo contrario
SI condición
Entonces
1.#.1 acción 1
1.#.2 acción 2
De lo contrario
1.*.1 acción 3
1.*.2 acción 4
1. (bloque) Si/Entonces/De lo contrario
SI condición
Entonces
1.>.1 acción 1
1.>.2 acción 2
De lo contrario
1.<.1 acción 3
1.<.2 acción 4
1. (bloque) Si/Entonces/De lo contrario
SI condición
Entonces
1.→.1 acción 1
1.→.2 acción 2
De lo contrario
1.←.1 acción 3
1.←.2 acción 4
1.△.1 acción 1 (para "Entonces")
1.▽.1 acción 3 (para "De lo contrario")
1. (bloque) Si/Entonces/De lo contrario
SI condición
Entonces
1.▶.1 acción 1
1.▶.2 acción 2
De lo contrario
1.◀.1 acción 3
1.◀.2 acción 4
1. (bloque) Si/Entonces/De lo contrario
SI condición
Entonces
1.✓.1 acción 1
1.✓.2 acción 2
De lo contrario
1.✗.1 acción 3
1.✗.2 acción 4
) : mejorar el « continuar solo si ».
