Ich wollte im Mockup die Verschachtelungsgrenze mehrerer Aktionen „Bedingte Blöcke Wenn… Dann… Sonst…“ angeben. Du hattest weiter oben geschrieben: « Grenzen für die Tiefe setzen (max 1 oder 2, denke ich) ». Heißt das, dass 1.A.1 das Maximum wäre? Oder 1.A.1.A.1? Oder 1.A.1.A.1.A.1? Ich würde mich für den mittleren Fall entscheiden
Ich wollte auch im Mockup den Geltungsbereich einer Verschiebung von Aktionsblöcken präzisieren. Technisch gesehen gibt es keine Grenzen, und man kann sich vorstellen, dass die Verschiebung eines Aktionsblocks aus einem „Dann“-Abschnitt innerhalb desselben „Dann“-Abschnitts möglich ist (z. B. vor 1.A.1.), oder im „Sonst“-Abschnitt (z. B. nach 1.S.2.), und sogar außerhalb der Aktion „Bedingte Blöcke Wenn… Dann… Sonst…“ (z. B. vor 3.). Aber nicht in einem „Wenn…“-Abschnitt, natürlich.
Gleiches gilt für die Verschiebung einer Aktion: Technisch gesehen gibt es keine Grenzen und man kann sie überall hin verschieben? Nun, außer in einem „Wenn…“-Abschnitt.
2/ Ich frage mich, ob wir die Buttons « Neue Aktion + » und « Neue Bedingung + » nicht verschieben könnten. Statt den rechten Teil dieser Abschnitte zu nutzen (der zu einem Collapse-Button werden könnte), könnten wir sie vielleicht als einen zentrierten Button am Ende des Abschnitts einfügen, der vielleicht nur ein kleines Icon sein könnte?
3/ Ich sehe nicht, wie man in deinem Design Aktionsgruppen hinzufügen/entfernen kann?
Bist du sicher? Eigentlich habe ich sie dort platziert, um mit dem zu bleiben, was heute existiert, um eine neue Aktion in einem Block hinzuzufügen. Wäre das, was du vorschlägst, in dieser Aktion « Bedingte Blöcke… » anzuwenden und auch in den Aktionsblöcken, die bereits heute existieren (denn sonst verfehlt man das Ziel der Kohärenz)? Wenn es das ist, denke ich, dass es ein anderes Thema ist, das man öffnen sollte, oder?
Nun, wie es bereits existiert:
zum Entfernen eines Aktionsblocks ist es das Papierkorb-Symbol. Es ist in meinen Schritten 1-2-3 nicht sichtbar, weil es nur einen Block gibt, aber man sieht sie gut in Schritt 4 für die Blöcke 1.A.1., 1.A.2., 1.S.1., 1.S.2.
zum Hinzufügen eines Aktionsblocks ist es automatisch, sobald du eine Aktion im letzten leeren Block hinzufügst. Ich habe es nicht explizit gemacht, aber ich kann eine Whimsical-Anmerkung hinzufügen, um es zu präzisieren.
Ich habe Schritt 4 meiner letzten Nachricht ersetzt, um einige erklärende Anmerkungen hinzuzufügen (aber keine Änderung des Designs, außer der Textzentrierung).
Ich glaube, wir kommen mit den letzten Punkten zu einer hervorragenden UI, großartig!
Ich würde hinzufügen (aber das wurde vielleicht schon gesagt): die Erstellung auf einen einzigen IF/THEN/ELSE-Abschnitt pro Hauptblock begrenzen (1. oder 2. oder 3. usw., ich hoffe, ich bin klar genug…).
Ah ja, ich verstehe, wovon du sprichst. Es ist nicht so, dass es unmöglich wäre, zwei Strukturen parallel zu verwalten, wenn… äh… sonst…, aber es ist einfach so, dass die beiden Aktionen grafisch untereinander dargestellt wären, was nicht intuitiv ihre parallele Ausführung widerspiegeln würde. Ich habe eine Anmerkung in Schritt 3 meiner vorherigen Nachricht hinzugefügt.
Ich denke, das ist eine andere Funktion, aber es wäre gut, wenn die Bedingung den aktuellen Wert eines Geräts annehmen könnte, ohne dass man diesen Wert vorher abrufen müsste? Ich weiß nicht, ob ich mich klar ausgedrückt habe?
Du hast recht, so bleibt die Entwicklung hier einfach.
Ich dachte, der „Zusammenfalten“-Button würde diese Buttons stören, aber eigentlich ist er nicht im gleichen Block.
Okay, tatsächlich!
Okay, danke!
Mal sehen, ich bin mir nicht sicher, ob diese Grenze so nützlich ist…
Andere Funktion!
Das nächste
@StephaneB Tatsächlich, ich denke, wir erreichen ein wirklich zufriedenstellendes Ergebnis in Bezug auf die UI! Glückwunsch!
Jetzt müssen wir überlegen/spezifizieren, was tatsächlich in diesen Bedingungen passiert.
Typischerweise verwendest du einen Satz von Bedingungen, die bereits existieren, aber eine sehr unterschiedliche Funktionsweise haben: Sie stoppen die Szene, wenn die Bedingung nicht erfüllt ist.
Man muss überlegen, wie man mit diesen neuen Bedingungen arbeiten wird: Sind es dieselben Bedingungen, aber anstatt die Szene zu stoppen, stoppt es nur den „aktuellen“ Ausführungsfluss?
Was ist mit den bestehenden Szenen?
Sind es völlig neue Bedingungen?
Man muss die gesamte Funktionsweise dieses neuen Systems definieren und schreiben
Übrigens, ich bin mir nicht sicher, ob ich das Design aller Bedingungen gesehen habe.
Danke!! Und danke an alle, die Feedback gegeben haben, um diese Oberfläche schrittweise zu verfeinern.
Also in meinem Kopf war das ganz einfach und ‹ logisch ›:
Die 5 aktuellen bedingten Aktionen tun tatsächlich das: Wenn die Bedingung erfüllt ist, dann setzt die Szene fort, andernfalls stoppt die Szene, wenn alle Aktionen des Blocks abgeschlossen sind.
Die 5 äquivalenten Bedingungen, die wir in einer Aktion « Bedingte Blöcke » verwenden werden, werden folgendes Verhalten haben: Wenn die Bedingung erfüllt ist (und alle anderen Bedingungen ebenfalls), dann setzt die Szene in dem Abschnitt « Dann… » fort, andernfalls setzt sie in dem Abschnitt « Sonst… » fort. Dann setzt die Szene in beiden Fällen in dem nächsten Aktionsblock fort.
Ist das das, was du meinst, wenn du « Spezifikation » sagst?
Ich verstehe diese Frage nicht. Eine mögliche Migration meinst du? Ich denke nicht, dass man das in Betracht ziehen sollte. Jeder wird entscheiden, wie er seine bestehenden Szenen neu bearbeitet, um die neue Aktion « Bedingte Blöcke » zu verwenden, oder?
Aus Sicht von UX/UI scheint es mir, dass es keinen Unterschied zwischen den 5 aktuellen bedingten Aktionen geben sollte. Somit wird die Verwendung in dem einen oder anderen Fall auf die gleiche Weise verstanden (außer dem Unterschied im Verhalten, der gerade beschrieben wurde).
Aber ist es technisch gesehen dasselbe Komponenten, das ist eher eine Aufgabe für die Entwicklung, oder?
Ich habe tatsächlich kein Beispiel mit « Bedingung auf EDF-Tempo » und « Bedingung auf einem Ereignis » gegeben, aber wenn ich sie hinzufüge, wird das nur zeigen, dass ihre Oberfläche genau dieselbe ist, ob man sie als bedingte Aktion oder als Bedingung in einer Aktion « Bedingte Blöcke » verwendet.
Das war’s, ich lasse dich wissen, was du brauchst, dass ich genauer spezifiziere.
Man muss von Fall zu Fall entscheiden, aber jede Bedingung, die derzeit in den Szenen vorhanden ist, ist dennoch eng mit dem Mechanismus zum „Fortsetzen/Unterbrechen der Szene“ verbunden.
Ich denke, es wäre sinnvoll, für jede Bedingung spezifische Mockups zu erstellen, um die Version „WENN… DANN“ zu definieren.
Das mag offensichtlich erscheinen, aber genau das ist das Ziel einer Spezifikation: gemeinsam im Voraus alles zu definieren, was entwickelt wird, auch wenn es offensichtlich erscheint.
Eine klare Spezifikation ermöglicht den Start der Entwicklung ohne Mehrdeutigkeiten.
Je detaillierter die Spezifikation ist, desto größer sind die Chancen, dass die Entwicklung erfolgreich ist!
Wenn wir davon ausgehen, dass es einen neuen Satz von Bedingungen gibt, der speziell für „WENN… DANN“ gedacht ist, dann braucht man keine Migration. Aber das war zu definieren!
Also habe ich meine Beweise und Logik beiseitegelegt , und habe die Texte aller 5 aktuellen bedingten Aktionen noch einmal gelesen. Hier ist mein Vorschlag, um die äquivalenten Bedingungen für die Aktion „Bedingte Blöcke (Wenn… Dann… Sonst…)“ zu erstellen:
@pierre-gilles, das ist ein Detail, aber ich finde, der Titel dieses Themas ist nicht mehr wirklich relevant. Was hältst du davon, ihn in ‹ Szene: neue Aktion « Bedingte Blöcke (Wenn… dann… sonst…) » › zu ändern?
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.
Ich habe heute Morgen ein bisschen herumgespielt, um eine Implementierung basierend auf deinem Vorschlag zu versuchen.
Bisher komme ich zu folgendem:
Das ist wirklich ein sehr schneller erster Entwurf!
Bei den Buttons « + Aktion hinzufügen » finde ich, dass es viel logischer ist, sie unten anzubringen, also habe ich das direkt in dieser Entwicklung getestet.
Bei dem « Dann… Sonst… » finde ich, dass das Einrahmen mit einer Karte die Oberfläche zu überladen macht, also habe ich nur einen Versatz eingeführt.
Bei dem Pfeil « > » zum Öffnen/Schließen von « Dann… Sonst… » bin ich schließlich bei einem Pfeil links gelandet, keine Ahnung, was du davon hältst?
Es fehlt noch vieles, aber ich finde es wirklich toll!
Das sieht wirklich gut aus. Ich kann es kaum erwarten, es zu nutzen!
Deine Entscheidungen erscheinen mir sinnvoll, kein Problem für mich…
Nur die Nummerierung der Blöcke: Das « 1.1.Then » ist seltsam.
« 1.1 » ist das, weil du denkst, dass mehrere Aktionen ‹ bedingte Blöcke › im Block « 1. » erlaubt sein sollten, die dann mit « 1.1 » und « 1.2 » usw. nummeriert werden? Ich habe es oben schon gesagt, ich denke, das wird die Lesbarkeit beeinträchtigen. Aber gut, das muss man testen…
Und nach dem Then sollte es schon ein « .1 » geben. Denn dann ist es sicher, dass man mehrere Aktionsblöcke aneinanderreihen kann, die mit « Then.1 », « Then.2 » usw. nummeriert werden.
Wir werden sehen, was in der Praxis funktioniert!
, und habe die Texte aller 5 aktuellen bedingten Aktionen noch einmal gelesen. Hier ist mein Vorschlag, um die äquivalenten Bedingungen für die Aktion „Bedingte Blöcke (Wenn… Dann… Sonst…)“ zu erstellen:
