it-swarm-eu.dev

Come definire interazioni e animazioni in modo estensibile?


L'intera domanda, riassunta per la responsabilità:

  • Come sarebbe meglio per un designer definire UI davvero complesse?
  • Sarebbe un buon approccio mappare come funziona il processo creativo mentale in strumenti?

Un giorno voglio creare un designer dell'interfaccia utente migliore per le applicazioni desktop rispetto a quello attualmente esistente (è un progetto a lungo termine) e sto già cercando di raccogliere pensieri sul fatto che sia possibile o meno avere un framework veramente estensibile.

Il problema principale che vedo è che devi essere in grado di scorrere tra le astrazioni di alto livello, come le interazioni tra i componenti, e le capacità di basso livello come applicare la sfocatura su una superficie semitrasparente. Ciò richiede buoni modelli di cosa sia composta un'interfaccia utente.

Un'animazione potrebbe essere qualsiasi cosa, dall'applicazione di effetti a un'immagine (come una sfocatura, o rumore, ecc.) Alla traduzione di oggetti in 3D, a far flare una luce attraverso un percorso mentre lo riempie, a qualsiasi cosa si possa immaginare .

Anche le interazioni sono complesse. Forse non vuoi che si verifichi un'animazione se ne è in corso un'altra, o se alcuni dati non sono presenti, ecc., Oppure potresti semplicemente attivare qualche azione su un evento.

Definire tutto questo dal codice, qualunque sia il codice che può essere, non è l'ideale. Voglio opinioni su come una cosa del genere possa essere "ideale", o semplicemente migliore, visivamente, dal punto di vista di un designer.

In altre parole, come sarebbe l'ambiente di progettazione UI/UX dei tuoi sogni ?

(nota: questi problemi si applicano anche al sito Web o al design mobile, quindi se hai opinioni in questi campi, sono i benvenuti anche).

Aggiornare:

Esporrò alcuni pensieri che ho su come potrebbe essere fatto.

Innanzitutto, uno degli obiettivi è quello di fare una separazione completa tra il lavoro del progettista e il lavoro del programmatore.

Ritengo che l'interfaccia utente e l'UX debbano essere prese in considerazione prima di scrivere qualsiasi logica applicativa - a volte, vedendo una GUI, è possibile vedere meglio quali funzionalità mancano e quali ingombri inutili.
Quindi il progettista dovrebbe essere in grado di creare interazioni complesse nell'interfaccia utente, anche se questa interfaccia utente non esegue alcun codice. Ciò semplifica anche il debug dell'interfaccia utente.

Pertanto, un'applicazione espone un'API all'interfaccia utente, composta da:

  • "Azioni" (con o senza parametri)
  • "Proprietà"
  • "Richieste" (ad es. Fucntions con parametri. Le funzioni senza parametri appariranno come proprietà)

Il progettista disporrà anche di strumenti che forniscono fonti di dati insignificanti in un formato personalizzato, quindi potrebbe ricorrere a "proprietà fasulle" nella configurazione di debug, proprio come un Lorem Ipsum.

Le proprietà esposte al progettista non possono essere nessun oggetto - saranno o un certo numero di semplici tipi di dati generici, come "Testo" (stringa), Numero intero, "Decimale" o persino "Immagine" (per semplice intendo = semplice per il progettista, ulteriori informazioni su come gestire i problemi di prestazioni in un secondo momento), array di qualche tipo semplice o "dati compositi", simili alla nozione di Tuples , a raggruppare diversi tipi di dati o array.
Ciò significa che il progettista può semplicemente richiedere i dati di cui ha bisogno o generare facilmente alcuni dati falsi per scopi di debug.

Ora, per quanto riguarda le prestazioni?

Bene, sappiamo tutti che generare la stessa immagine più e più volte sarebbe costoso, ma il designer non è pensato per pensarci troppo. Invece, la richiesta ripetitiva allo stesso elemento verrebbe memorizzata nella cache da un intermediario tra il codice dell'applicazione (fatto dal programmatore) e l'interfaccia utente, nell'API.

Sto ancora pensando ai dettagli di implementazione di questo, ma significherà che un programmatore potrebbe dire all'API che chiama la stessa funzione con gli stessi parametri più e più volte genererà lo stesso risultato e l'API memorizzerà in cache i risultati di questa funzione in modo intelligente.
In qualsiasi modo ciò possa essere implementato, sarà trasparente per il progettista, poiché questo è l'obiettivo.

A proposito di alcuni concetti a cui sto pensando per la composizione dell'interfaccia utente:

(termini abbastanza autoesplicativi)

Superfici: Componenti di base dell'interfaccia utente che hanno proprietà e una forma e sono associati a un materiale. Internamente rappresentato in formato vettoriale.
Materiale: Elemento condiviso nell'interfaccia utente che può definire in un posto lo stile di più elementi (come riempimenti sfumati o di trama, bordi , rilascia ombre, ecc.).
Componenti: Pezzi dell'interfaccia utente con logica propria, che potrebbero fare cose più avanzate rispetto alle superfici, come la generazione di effetti particellari , collegandosi ad altri componenti in modo reciprocamente interattivo e persino generando loro sottocomponenti. Ciò renderà più semplici alcuni effetti come un "cerchio" animato di cerchi ( come questo ). Conterranno un linguaggio di scripting, forse un motore Javascript.
Effetti/Transizioni: Questi sono pensati per essere innescati da altre parti dell'interfaccia utente o da cambiamenti di stato. Cose come ButtonFoo.Glow o PanelBar.MoveToLeft nominato e progettato dal designer e raggruppato in un sistema simile allo spazio dei nomi.
Stati: Rappresentano lo stato corrente dell'interfaccia utente e possono essere utilizzati dai trigger.
Trigger: Questi attivano determinati effetti o transizioni.
Condizioni: Questi sono controlli che possono essere associati ai trigger.

Il progettista sarà anche in grado di esporre i dati al programmatore, tramite un sistema che assomiglia alle proprietà consumate dal lato del progettista.

7
Camilo Martin

Penso che l'utente possa concentrarsi su una cosa alla volta: può essere una vista nella gerarchia di viste (1), altrimenti quando abbiamo molte viste di interazione allo stesso tempo, queste viste dovrebbero essere (saranno buone) indipendenti (2 ). Quindi nel caso (1) l'applicazione può controllare la vista corrente dello stato e nel caso (2) l'applicazione non ha bisogno di sincronizzare lo stato delle viste indipendenti.

Ad esempio, lo sviluppatore dovrebbe implementare una macchina a stati finiti guidata dagli eventi per elaborare lo stato di tutte le viste dipendenti o dovrebbe usare trigger dell'interfaccia utente per riprodurre le animazioni.

1
igor