it-swarm-eu.dev

Wie definiere ich Interaktionen und Animationen auf erweiterbare Weise?


Die ganze Frage, zusammengefasst zur Beantwortung:

  • Wie wäre es für einen Designer Am besten, wirklich komplexe Benutzeroberflächen zu definieren?
  • Wäre es ein guter Ansatz, die Funktionsweise des mentalen Kreativprozesses in Tools abzubilden?

Eines Tages möchte ich einen besseren UI-Designer für Desktop-Anwendungen entwickeln als das, was derzeit existiert (es ist ein langfristiges Projekt), und ich versuche bereits, Gedanken darüber zu sammeln, ob es möglich ist, ein wirklich erweiterbares Framework zu haben oder nicht.

Das Hauptproblem, das ich sehe, besteht darin, dass Sie in der Lage sein müssen, zwischen Abstraktionen auf hoher Ebene wie Interaktionen zwischen Komponenten und Funktionen auf niedriger Ebene wie dem Anwenden von Unschärfe auf eine halbtransparente Oberfläche zu iterieren. Dies erfordert gute Modelle der Zusammensetzung einer Benutzeroberfläche.

Eine "Animation" kann alles sein, von der Anwendung von Effekten auf ein Bild (wie Unschärfe oder Rauschen usw.) über die Übersetzung von Objekten in 3D bis hin zu einer Lichtfackel, die sich beim Füllen durch einen Pfad bewegt, bis zu allem, was man sich vorstellen kann .

Wechselwirkungen sind ebenfalls komplex. Vielleicht möchten Sie nicht, dass eine Animation ausgeführt wird, wenn eine andere ausgeführt wird oder wenn einige Daten nicht vorhanden sind usw., oder lösen Sie einfach eine Aktion für ein Ereignis aus.

Es ist nicht ideal, all dies aus Code zu definieren, unabhängig davon, um welchen Code es sich handelt. Ich möchte Meinungen darüber, wie so etwas aus der Sicht eines Designers "ideal" oder einfach besser visuell sein könnte.

Mit anderen Worten, wie würde die UI/UX-Designumgebung Ihrer Träume aussehen?

(Hinweis: Diese Probleme gelten auch für das Design von Websites oder Mobilgeräten. Wenn Sie also Meinungen zu diesen Bereichen haben, sind sie auch willkommen.).

Aktualisieren:

Ich werde einige Gedanken darüber aufzeigen, wie es gemacht werden könnte.

Eines der Ziele ist in erster Linie eine vollständige Trennung zwischen der Arbeit des Designers und der Arbeit des Programmierers.

Ich bin der Meinung, dass die Benutzeroberfläche und die Benutzeroberfläche vor dem Schreiben einer Anwendungslogik berücksichtigt werden sollten. Manchmal kann man anhand einer grafischen Benutzeroberfläche besser erkennen, welche Funktionen fehlen und welche unnötig sind.
Der Designer sollte also in der Lage sein, komplexe Interaktionen in der Benutzeroberfläche zu erstellen, auch wenn diese Benutzeroberfläche keinen Code ausführt. Dies erleichtert auch das Debuggen der Benutzeroberfläche.

Eine Anwendung würde also eine API für die Benutzeroberfläche verfügbar machen, die sich zusammensetzt aus:

  • "Aktionen" (mit oder ohne Parameter)
  • "Eigenschaften"
  • "Anfragen" (d. H. Funktionen mit Parametern. Parameterlose Funktionen sehen wie Eigenschaften aus)

Der Designer wird auch über Tools verfügen, die bedeutungslose Datenquellen in einem benutzerdefinierten Format bereitstellen, sodass er/sie möglicherweise Daten zur "Fälschung von Eigenschaften" bei der Debug-Konfiguration bindet, ähnlich wie bei einem Lorem Ipsum.

Eigenschaften, die dem Designer zur Verfügung gestellt werden, können kein Objekt sein - es handelt sich entweder um eine Reihe einfacher generischer Datentypen wie "Text" (Zeichenfolge), Ganzzahl, "Dezimal" oder sogar "Bild" (mit einfach meine ich = einfach für den Designer, mehr darüber, wie Leistungsprobleme später behandelt werden), Arrays eines einfachen Typs oder "zusammengesetzte Daten", ähnlich dem Begriff Tupel , to Gruppieren Sie mehrere Datentypen oder Arrays.
Dies bedeutet, dass der Designer einfach nach den benötigten Daten fragen oder leicht gefälschte Daten für Debug-Zwecke generieren kann.

Was ist nun mit der Leistung?

Wir alle wissen, dass es teuer wäre, immer wieder dasselbe Bild zu erstellen, aber der Designer sollte nicht zu viel darüber nachdenken. Stattdessen wird eine wiederholte Anforderung an dasselbe Element von einem Vermittler zwischen dem vom Programmierer erstellten Anwendungscode und der Benutzeroberfläche in der API zwischengespeichert.

Ich denke immer noch über die Implementierungsdetails nach, aber dies bedeutet, dass ein Programmierer der API mitteilen kann, dass immer wieder dieselbe Funktion mit denselben Parametern aufgerufen wird, dasselbe Ergebnis generiert wird und die API die Ergebnisse dieser Funktion intelligent zwischenspeichert.
In irgendeiner Weise könnte dies implementiert werden, es wird für den Designer transparent sein, da dies das Ziel ist.

Über einige Konzepte, an die ich für die UI-Komposition denke:

(ziemlich selbsterklärende Begriffe)

Oberflächen: Grundlegende Komponenten der Benutzeroberfläche, die Eigenschaften und eine Form haben und an ein Material gebunden sind. Intern im Vektorformat dargestellt.
Material: Gemeinsames Element in der Benutzeroberfläche, das an einer Stelle den Stil mehrerer Elemente definieren kann (z. B. Verlaufs- oder Texturfüllungen, Rahmen) , Schlagschatten usw.).
Komponenten: Teile der Benutzeroberfläche mit eigener Logik, die fortgeschrittenere Aufgaben als Oberflächen ausführen können, z. B. das Generieren von Partikeleffekte , die sich gegenseitig interaktiv mit anderen Komponenten verbinden und sogar eigene Unterkomponenten erzeugen. Dadurch werden bestimmte Effekte wie ein animierter "Laden" von Kreisen ( wie dieser ) einfacher zu erstellen. Sie enthalten eine Skriptsprache, möglicherweise eine Javascript-Engine.
Effekte/Übergänge: Diese sollen durch andere Teile der Benutzeroberfläche oder Statusänderungen ausgelöst werden. Dinge wie ButtonFoo.Glow oder PanelBar.MoveToLeft vom Designer benannt und entworfen und in einem namespaceähnlichen System gruppiert.
Zustände: Diese stellen den aktuellen Zustand der Benutzeroberfläche dar und können von Triggern verwendet werden.
Auslöser: Diese lösen bestimmte Effekte oder Übergänge aus.
Bedingungen: Dies sind Prüfungen, die an Trigger angehängt werden können.

Der Designer kann dem Programmierer auch Daten über ein System zur Verfügung stellen, das den verbrauchten Eigenschaften von Seiten des Designers ähnelt.

7
Camilo Martin

Ich denke, der Benutzer kann sich zu einem bestimmten Zeitpunkt auf eines konzentrieren: Es kann sich um eine Ansicht in der Ansichtshierarchie handeln (1). Wenn wir jedoch viele Interaktionsansichten gleichzeitig haben, sollte diese Ansicht unabhängig sein (wird gut sein) (2) ). Im Fall (1) kann die Anwendung die aktuelle Statusansicht steuern, und im Fall (2) muss die Anwendung den Status unabhängiger Ansichten nicht synchronisieren.

Beispielsweise sollte der Entwickler eine ereignisgesteuerte Finite-State-Maschine implementieren, um den Status aller abhängigen Ansichten zu verarbeiten, oder I-Trigger verwenden, um Animationen abzuspielen.

1
igor